File: rfc1095.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (3755 lines) | stat: -rw-r--r-- 153,752 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
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
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755






Network Working Group                                         U. Warrier
Request for Comments: 1095                            Unisys Corporation
                                                                L. Besaw
                                                         Hewlett-Packard
                                                              April 1989


  The Common Management Information Services and Protocol over TCP/IP
                                 (CMOT)

                        Table of Contents

1. Status of this Memo ............................................    3
2. Introduction ...................................................    4
Part I: Concepts and Models .......................................    7
3. The OSI Management Framework ...................................    7
3.1. Architectural Overview .......................................    7
3.2. Management Models ............................................    8
3.2.1. The Organizational Model ...................................    8
3.2.2. The Functional Model .......................................    8
3.2.3. The Information Model ......................................    9
3.3. ISO Application Protocols ....................................    9
3.3.1. ACSE .......................................................   10
3.3.2. ROSE .......................................................   10
3.3.3. CMISE ......................................................   10
3.3.3.1. Management Association Services ..........................   11
3.3.3.2. Management Notification Services .........................   12
3.3.3.3. Management Operation Services ............................   12
4. The CMOT Architecture ..........................................   13
4.1. Management Models ............................................   13
4.1.1. The Organizational Model ...................................   13
4.1.2. The Functional Model .......................................   14
4.1.3. The Information Model ......................................   14
4.2. Protocol Architecture ........................................   14
4.2.1 The Lightweight Presentation Layer ..........................   15
4.2.2 The Quality of Transport Service ............................   16
4.3. Proxy Management .............................................   17
4.4. Directory Service ............................................   18
5. Management Information .........................................   18
5.1. The Structure of Management Information ......................   19
5.1.1. The ISO SMI ................................................   19
5.1.1.1. Managed Objects and Attributes ...........................   19
5.1.1.2. Management Information Hierarchies .......................   20
5.1.1.2.1 The Registration Hierarchy ..............................   20
5.1.1.2.2. The Containment Hierarchy ..............................   20
5.1.1.2.3. The Inheritance Hierarchy ..............................   22
5.1.2. The Internet SMI ...........................................   22
5.2. The Management Information Base ..............................   23



Warrier & Besaw                                                 [Page 1]

RFC 1095                          CMOT                        April 1989


5.3. An Interpretation of the Internet SMI ........................   24
5.3.1. Object Class and Attributes ................................   25
5.3.1.1. Object Class .............................................   25
5.3.1.2. Attribute Identifier .....................................   26
5.3.2. Management Information Hierarchies .........................   26
5.3.2.1. The Registration Hierarchy ...............................   26
5.3.2.2. The Containment Hierarchy ................................   26
5.3.2.3. The Inheritance Hierarchy ................................   28
5.4. Scoping, Filtering, and Synchronization ......................   28
5.4.1. Scoping ....................................................   28
5.4.2. Filtering ..................................................   29
5.4.3. Synchronization ............................................   29
5.4.4. Linked Replies .............................................   29
5.5. Accessing Tables .............................................   29
5.5.1. Accessing Whole Tables .....................................   30
5.5.2. Accessing Table Entries ....................................   30
Part II: Protocol Agreements ......................................   32
6. CMOT Protocol Overview .........................................   32
6.1. The CMOT Protocol Suite ......................................   32
6.2. Conformance Requirements .....................................   33
6.3. Abstract Syntax Notation .....................................   33
7. Common Management Information Service Element ..................   34
7.1. CMIS Services ................................................   34
7.1.1. CMIS Services Overview .....................................   34
7.1.2. Functional Units ...........................................   34
7.1.3. Functional Unit Groups .....................................   36
7.1.4. M-INITIALISE Parameters ....................................   37
7.1.4.1. Functional Units .........................................   37
7.1.4.2. User Information .........................................   39
7.1.4.3. Access Control ...........................................   39
7.2. Supporting Services ..........................................   39
7.3. CMIP Agreements ..............................................   39
7.3.1. Invoke Identifier ..........................................   39
7.3.2. Object Class ...............................................   40
7.3.3. Object Instance ............................................   40
7.3.4. Access Control .............................................   41
7.3.5. Synchronization ............................................   41
7.3.6. Scope ......................................................   41
7.3.7. Filter .....................................................   41
7.3.8. Attribute Identifier .......................................   42
7.3.9. Event Type Identifier ......................................   42
7.3.10. Action Type Identifier ....................................   42
7.3.11. Time Fields ...............................................   43
7.3.12. Response PDUs .............................................   43
7.3.13. Error PDUs ................................................   43
8. Association Control Service Element ............................   43
8.1. ACSE Services ................................................   44
8.2. Supporting Services ..........................................   44



Warrier & Besaw                                                 [Page 2]

RFC 1095                          CMOT                        April 1989


8.3. ACSE Protocol ................................................   45
8.3.1. Application Context Name ...................................   45
8.3.2. User Information ...........................................   45
8.3.3. Presentation Service Parameters ............................   46
9. Remote Operations Service Element ..............................   46
9.1. ROSE Services ................................................   46
9.2. Supporting Services ..........................................   47
9.3. ROSE Protocol ................................................   47
9.3.1. Operation Class ............................................   47
9.3.2. Priority ...................................................   48
10. Lightweight Presentation ......................................   48
10.1. Lightweight Presentation Services ...........................   48
10.2. Supporting Services .........................................   48
10.3. Lightweight Presentation Protocol ...........................   49
11. Acknowledgements ..............................................   49
12. References ....................................................   49
Appendix A - The CMOT Group .......................................   52
Appendix B - Management Information Summary .......................   53
Appendix C - Sample Protocol Exchanges ............................   60

1.  Status of this Memo

   This memo defines a network management architecture that uses the
   International Organization for Standardization's (ISO) Common
   Management Information Services/Common Management Information
   Protocol (CMIS/CMIP) in a TCP/IP environment.  This architecture
   provides a means by which control and monitoring information can be
   exchanged between a manager and a remote network element.  In
   particular, this memo defines the means for implementing the Draft
   International Standard (DIS) version of CMIS/CMIP on top of Internet
   transport protocols for the purpose of carrying management
   information defined in the Internet-standard management information
   base.  DIS CMIS/CMIP is suitable for deployment in TCP/IP networks
   while CMIS/CMIP moves toward becoming an International Standard.
   Together with the relevant ISO standards and the companion RFCs that
   describe the initial structure of management information and
   management information base, these documents provide the basis for a
   comprehensive architecture and system for managing TCP/IP-based
   internets, and in particular the Internet.

   The Internet Activities Board (IAB) has designated two different
   network management protocols with the same status of "Draft Standard"
   and "Recommended".

   The two protocols are the Common Management Information Services and
   Protocol over TCP/IP (CMOT) (this memo) and the Simple Network
   Management Protocol (SNMP) [4].




Warrier & Besaw                                                 [Page 3]

RFC 1095                          CMOT                        April 1989


   The IAB intends each of these two protocols to receive the attention
   of implementers and experimenters.  The IAB seeks reports of
   experience with these two protocols from system builders and users.

   By this action, the IAB recommends that all IP and TCP
   implementations be network manageable (e.g., implement the Internet
   MIB [3], and that implementations that are network manageable are
   expected to adopt and implement at least one of these two Internet
   Draft Standards.

   Distribution of this memo is unlimited.

2.  Introduction

   As reported in RFC 1052, "IAB Recommendations for the Development of
   Internet Network Management Standards" [1], the Internet Activities
   Board (IAB) has directed the Internet Engineering Task Force (IETF)
   to coordinate the work of three working groups in the area of network
   management. First, the MIB working group was charged with the
   specification and definition of elements to be included in the
   Management Information Base (MIB).  Second, the SNMP working group
   was charged with defining the modifications to the Simple Network
   Management Protocol (SNMP) necessary to accommodate the short-term
   needs of the network vendor and operations communities.  Third, the
   Netman working group was directed to meet the longer-term needs of
   the Internet community by developing a network management system
   based on ISO CMIS/CMIP.  Both the Netman working group and the SNMP
   working group were directed to align their work with the output of
   the MIB working group in order to ensure compatibility of management
   information between the short-term and long-term approaches to the
   management of TCP/IP-based internets.  This will enable a smooth
   transition from the short-term protocol (SNMP) to the long-term
   protocol (CMIP).

   The MIB working group has produced two memos.  RFC 1065 [2] defines
   the Structure of Management Information (SMI) that is necessary for
   naming and defining managed objects in the MIB.  RFC 1066 [3] defines
   the list of managed objects contained in the initial TCP/IP MIB.  The
   SNMP working group has produced a memo [4] giving the protocol
   specification for SNMP and providing the SNMP protocol-specific
   interpretation of the Internet-standard MIB defined in RFC 1066.

   This memo is the output of the Netman working group.  As directed by
   the IAB in RFC 1052, it addresses the need for a long-term network
   management system based on ISO CMIS/CMIP.  The network management
   approach of using ISO protocols in a TCP/IP environment to manage
   TCP/IP networks can be described as "CMIP Over TCP/IP" (CMOT).  This
   memo specifies the CMOT architecture and the protocol agreements



Warrier & Besaw                                                 [Page 4]

RFC 1095                          CMOT                        April 1989


   necessary to implement CMIP and accompanying ISO protocols over the
   TCP and UDP transport protocols.  In addition, this memo provides an
   interpretation of RFC 1066 that makes it possible to use CMIP to
   convey management information defined in the Internet-standard MIB.

   There is widespread vendor support for the CMOT approach to network
   management.  This is amply shown by the Netman demonstration of
   prototype CMOT implementations at the Interop '88 TCP/IP
   Interoperability Conference.  The demonstration also showed the
   feasibility and power of the CMIS/CMIP framework for multivendor
   network management.  Now that CMIS/CMIP has been voted a Draft
   International Standard (DIS), many vendors feel that the ISO standard
   has become a stable basis for product development.  The clear need to
   standardize this development has led to the present profile of CMIP.
   It is expected that this profile will not change while the ISO
   standard moves from DIS status to International Standard (IS) status.
   If, however, the standard does change unexpectedly, the Netman
   working group will review such changes for appropriate action.

   Another rationale for the CMOT approach is that it will facilitate
   the early use of ISO network management standards in large
   operational networks.  This will make it possible for the Internet
   community to make valuable recommendations to ISO in the language of
   OSI management based on actual experience with the use and
   implementation of these standards.  There is continuing network
   management standards development work in ISO where such contributions
   would be valuable.

   The CMOT architecture is based on the Open Systems Interconnection
   (OSI) management framework and models developed by ISO.  This memo
   contains a set of protocol agreements for implementing a network
   management system based on this architecture. The protocol agreement
   sections of this memo must be read in conjunction with ISO and
   Internet documents defining specific protocol standards.  Documents
   defining the following ISO standards are required for the
   implementor: Abstract Syntax Notation One (ASN.1) [5, 6], Association
   Control (ACSE) [7, 8], Remote Operations (ROSE) [9, 10], Common
   Management Information Services (CMIS) [11], and Common Management
   Information Protocol (CMIP) [12].  RFC 1085 [13] is required for the
   specification of a lightweight presentation layer protocol used in
   this profile.  In addition, RFC 1065 [2] and RFC 1066 [3] are
   required for a definition of the initial SMI and MIB to be used with
   the CMOT management system.

   This memo is divided into two main parts.  The first part presents
   concepts and models; the second part contains the protocol agreements
   necessary for implementation of the CMOT network management system.
   The first part of the memo is divided into three sections: section 3



Warrier & Besaw                                                 [Page 5]

RFC 1095                          CMOT                        April 1989


   contains tutorial information on the OSI management framework;
   section 4 defines the basic CMOT approach; and section 5 discusses
   the area of management information and specifies how the abstract
   management information defined in the Internet-standard SMI and MIB
   map into CMIP.  The second part of this memo is divided into sections
   for each of the protocols for which implementors' agreements are
   needed: CMISE, ACSE, ROSE, and the lightweight presentation protocol.
   The protocol profile defined in this part draws on the technical work
   of the OSI Network Management Forum [14] and the Network Management
   Special Interest Group (NMSIG) of the National Institute of Standards
   and Technology (NIST) (formerly the National Bureau of Standards).
   Wherever possible, an attempt has been made to remain consistent with
   the protocol agreements reached by these groups.






































Warrier & Besaw                                                 [Page 6]

RFC 1095                          CMOT                        April 1989


                        Part I: Concepts and Models

3.  The OSI Management Framework

   The OSI management framework [15] presents the basic concepts and
   models required for developing network management standards.  OSI
   management provides the ability to monitor and control network
   resources, which are represented as "managed objects." The following
   elements are essential for the description of a network management
   architecture and the standardization of a network management system:
   a model or set of models for understanding management; a common
   structure of management information for registering, identifying, and
   defining managed objects; detailed specifications of the managed
   objects; and a set of services and related protocols for performing
   remote management operations.

3.1.  Architectural Overview

   The basic concepts underlying OSI network management are quite simple
   [16].  There reside application processes called "managers" on
   managing systems (or management stations).  There reside application
   processes called "agents" on managed systems (or network elements
   being managed).  Network management occurs when managers and agents
   conspire (via protocols and a shared conceptual schema) to exchange
   monitoring and control information useful to the management of a
   network and its components.  The terms "manager" and "agent" are also
   used in a loose and popular sense to refer to the managing and
   managed system, respectively.

   The shared conceptual schema mentioned above is a priori knowledge
   about "managed objects" concerning which information is exchanged.
   Managed objects are system and networking resources (e.g., a modem, a
   protocol entity, an IP routing table, a TCP connection) that are
   subject to management. Management activities are effected through the
   manipulation of managed objects in the managed systems.  Using the
   management services and protocol, the manager can direct the agent to
   perform an operation on a managed object for which it is responsible.
   Such operations might be to return certain values associated with a
   managed object (read a variable), to change certain values associated
   with a managed object (set a variable), or perform an action (such as
   self-test) on the managed object.  In addition, the agent may also
   forward notifications generated asynchronously by managed objects to
   the manager (events or traps).

   The terms "manager" and "agent" are used to denote the asymmetric
   relationship between management application processes in which the
   manager plays the superior role and the agent plays the subordinate.




Warrier & Besaw                                                 [Page 7]

RFC 1095                          CMOT                        April 1989


   However, the specification of the management protocol (CMIP) defines
   a peer protocol relationship that makes no assumptions concerning
   which end opens or closes a connection, or the direction of
   management data transfer.  The protocol mechanisms provided are fully
   symmetric between the manager and the agent; CMIS operations can
   originate at either the manager or agent, as far as the protocol is
   concerned.  This allows the possibility of symmetric as well as
   asymmetric relationships between management processes.  Most devices
   will contain management applications that can only assume the agent
   role.  Applications on managing systems, however, may well be able to
   play both roles at the same time.  This makes possible "manager to
   manager" communication and the ability of one manager to manage
   another.

3.2.  Management Models

   Network management may be modeled in different ways.  Three models
   are typically used to describe OSI management [17, 18].  An
   organizational model describes ways in which management can be
   administratively distributed.  The functional model describes the
   management functions and their relationships.  The information model
   provides guidelines for describing managed objects and their
   associated management information.

3.2.1.  The Organizational Model

   The organizational model introduces the concept of a management
   "domain." A domain is an administrative partition of a network or
   internet for the purpose of network management.  Domains may be
   useful for reasons of scale, security, or administrative autonomy.
   Each domain may have one or more managers monitoring and controlling
   agents in that domain.  In addition, both managers and agents may
   belong to more than one management domain.  Domains allow the
   construction of both strict hierarchical and fully cooperative and
   distributed network management systems.

3.2.2.  The Functional Model

   The OSI Management Framework [15] defines five facilities or
   functional areas to meet specific management needs. This has proved
   to be a helpful way of partitioning the network management problem
   from an application point of view.  These facilities have come to be
   known as the Specific Management Functional Areas (SMFAs): fault
   management, configuration management, performance management,
   accounting management, and security management.  Fault management
   provides the ability to detect, isolate, and correct network
   problems.  Configuration management enables network managers to
   change the configuration of remote network elements.  Performance



Warrier & Besaw                                                 [Page 8]

RFC 1095                          CMOT                        April 1989


   management provides the facilities to monitor and evaluate the
   performance of the network.  Accounting management makes it possible
   to charge users for network resources used and to limit the use of
   those resources.  Finally, security management is concerned with
   managing access control, authentication, encryption, key management,
   and so on.

3.2.3.  The Information Model

   The OSI Management Framework considers all information relevant to
   network management to reside in a Management Information Base (MIB),
   which is a "conceptual repository of management information."
   Information within a system that can be referenced by the management
   protocol (CMIP) is considered to be part of the MIB.  Conventions for
   describing and uniquely identifying the MIB information allow
   specific MIB information to be referenced and operated on by the
   management protocol.  These conventions are called the Structure of
   Management Information (SMI).  The information model is described
   more fully in section 5.

3.3.  ISO Application Protocols

   The following ISO application services and protocols are necessary
   for doing network management using the OSI framework: ACSE, ROSE, and
   CMIS/CMIP.  All three of these protocols are defined using ASN.1 [5].
   The ASN.1 modules defining each of these protocols are found in the
   relevant standards documents.  The encoding rules for ASN.1 [6]
   provide a machine-independent network representation for data.

   A brief overview of the terminology associated with the OSI
   application layer structure is presented here.  A complete treatment
   of the subject can be found in the OSI Application Layer Structure
   document [22].

   In the OSI environment, communication between "application processes"
   is modeled by communication between application entities.  An
   "application entity" represents the communication functions of an
   application process.  There may be multiple sets of OSI communication
   functions in an application process, so a single application process
   may be represented by multiple application entities.  However, each
   application entity represents a single application process.  An
   application entity contains a set of communication capabilities
   called "application service elements." An application service element
   is a coherent set of integrated functions.  These application service
   elements may be used independently or in combination.  Examples of
   application service elements are X.400, FTAM, ACSE, ROSE, and CMISE.

   When communication is required between two application entities, one



Warrier & Besaw                                                 [Page 9]

RFC 1095                          CMOT                        April 1989


   or more "application associations" are established between them.
   Such an association can be viewed as a connection at the level of the
   application layer.  An "application context" defines the set of
   application service elements which may be invoked by the user of an
   application association.  The application context may prescribe one
   or more application service elements.

   Generally, an "application layer protocol" is realized by the use of
   the functionality of a number of application service elements.  This
   functionality is provided by the specification of a set of
   application protocol data units (APDUs) and the procedures governing
   their use.  In general, the operation of an application layer
   protocol may require the combination of APDUs from different
   application service elements.  The application entity makes direct
   use of presentation context identifiers for the specification and
   identification of APDUs.

3.3.1.  ACSE

   The Association Control Service Element (ACSE) is used to establish
   and release associations between application entities. Before any
   management operations can be performed using CMIP, it is necessary
   for the two application entities involved to form an association.
   Either the manager or the agent can initiate association
   establishment.  ACSE allows the manager and agent to exchange
   application entity titles for the purpose of identification and
   application context names to establish an application context. As
   stated above, an application context defines what service elements
   (for instance, ROSE and CMISE) may be used over the association.
   After the association is established, ACSE is not used again until
   the association is released by the manager or agent.

3.3.2.  ROSE

   The Remote Operation Service Element (ROSE) is the ISO equivalent of
   remote procedure call.  ROSE allows the invocation of an operation to
   be performed on a remote system.  The Remote Operation protocol
   contains an invoke identifier for correlating requests and responses,
   an operation code, and an argument field for parameters specific to
   the operation.  ROSE can only be invoked once an application
   association has been established.  CMIP uses the transaction-oriented
   services provided by ROSE for all its requests and responses.  CMIP
   also uses the error response facilities provided by ROSE.

3.3.3.  CMISE

   The Common Management Information Service Element (CMISE) is the
   service element that provides the basic management services.  The



Warrier & Besaw                                                [Page 10]

RFC 1095                          CMOT                        April 1989


   CMISE is a user of both ROSE and ACSE.  The CMISE provides both
   confirmed and unconfirmed services for reporting events and
   retrieving and manipulating management data. These services are used
   by manager and agent application entities to exchange management
   information.  Table 1 provides a list of the CMISE services.  In
   addition, the CMISE also provides the ability to issue a series of
   (multiple) linked replies in response to a single request.


           +-----------------+-------------------------+
           |    Service      |     Type                |
           +-----------------+-------------------------+
           |  M-INITIALISE   | confirmed               |
           |  M-TERMINATE    | confirmed               |
           |  M-ABORT        | non-confirmed           |
           |  M-EVENT-REPORT | confirmed/non-confirmed |
           |  M-GET          | confirmed               |
           |  M-SET          | confirmed/non-confirmed |
           |  M-ACTION       | confirmed/non-confirmed |
           |  M-CREATE       | confirmed               |
           |  M-DELETE       | confirmed               |
           +-----------------+-------------------------+

                Table 1.  CMISE Service Summary


   CMIS services can be divided into two main classes: management
   association services and information transfer services.  Furthermore,
   there are two types of information transfer services: management
   notification services and management operation services.  In addition
   to the other CMIS services, the CMISE provides facilities that enable
   multiple responses to confirmed operations to be linked to the
   operation by the use of a linked identification parameter.

3.3.3.1.  Management Association Services

   CMIS provides services for the establishment and release of
   application associations.  These services control the establishment
   and normal and abnormal release of a management association. These
   services are simply pass-throughs to ACSE.

   The M-INITIALISE service is invoked by a CMISE-service-user to
   establish an association with a remote CMISE-service-user for the
   purpose of exchanging management information. A reply is expected.
   (A CMISE-service-user is that part of an application process that
   makes use of the CMISE.)

   The M-TERMINATE service is invoked by a CMISE-service-user to release



Warrier & Besaw                                                [Page 11]

RFC 1095                          CMOT                        April 1989


   an association with a remote CMISE-service-user in an orderly manner.
   A reply is expected.

   The M-ABORT service is invoked by a CMISE-service-user or a CMISE-
   service-provider to release an association with a remote CMISE-
   service-user in an abrupt manner.

3.3.3.2.  Management Notification Services

   The definition of notification and the consequent behavior of the
   communicating entities is dependent upon the specification of the
   managed object which generated the notification and is outside the
   scope of CMIS.  CMIS provides the following service to convey
   management information applicable to notifications.

   The M-EVENT-REPORT service is invoked by a CMISE-service-user to
   report an event about a managed object to a remote CMISE-service-
   user.  The service may be requested in a confirmed or a non-confirmed
   mode.  In the confirmed mode, a reply is expected.

3.3.3.3.  Management Operation Services

   The definition of the operation and the consequent behavior of the
   communicating entities is dependent upon the specification of the
   managed object at which the operation is directed and is outside the
   scope of CMIS.  However, certain operations are used frequently
   within the scope of management and CMIS provides the following
   definitions of the common services that may be used to convey
   management information applicable to the operations.

   The M-GET service is invoked by a CMISE-service-user to request the
   retrieval of management information from a remote CMISE-service-user.
   The service may only be requested in a confirmed mode.  A reply is
   expected.

   The M-SET service is invoked by a CMISE-service-user to request the
   modification of management information by a remote CMISE-service-
   user.  The service may be requested in a confirmed or a non-confirmed
   mode.  In the confirmed mode, a reply is expected.

   The M-ACTION service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to perform an action.  The service may be
   requested in a confirmed or a non-confirmed mode.  In the confirmed
    mode, a reply is expected.

   The M-CREATE service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to create another instance of a managed
   object.  The service may only be requested in a confirmed mode.  A



Warrier & Besaw                                                [Page 12]

RFC 1095                          CMOT                        April 1989


   reply is expected.

   The M-DELETE service is invoked by a CMISE-service-user to request a
   remote CMISE-service-user to delete an instance of a managed object.
   The service may only be requested in a confirmed mode.  A reply is
   expected.

4.  The CMOT Architecture

   The CMOT (CMIP Over TCP/IP) architecture is based on the OSI
   management framework [15] and the models, services, and protocols
   developed by ISO for network management.  The CMOT architecture
   demonstrates how the OSI management framework can be applied to a
   TCP/IP environment and used to manage objects in a TCP/IP network.
   The use of ISO protocols for the management of widely deployed TCP/IP
   networks will facilitate the ultimate migration from TCP/IP to ISO
   protocols.  The concept of proxy management is introduced as a useful
   extension to the architecture.  Proxy management provides the ability
   to manage network elements that either are not addressable by means
   of an Internet address or use a network management protocol other
   than CMIP.

   The CMOT architecture specifies all the essential components of a
   network management architecture.  The OSI management framework and
   models are used as the foundation for network management.  A
   protocol-dependent interpretation of the Internet SMI [2] is used for
   defining management information.  The Internet MIB [3] provides an
   initial list of managed objects.  Finally, a means is defined for
   using ISO management services and protocols on top of TCP/IP
   transport protocols.  Management applications themselves are not
   included within the scope of the CMOT architecture.  What is
   currently standardized in this architecture is the minimum required
   for building an interoperable multivendor network management system.
   Applications are explicitly left as a competitive issue for network
   developers and providers.

4.1.  Management Models

   The following sections indicate how the CMOT architecture applies the
   OSI managements models and point out any limitations the CMOT
   architecture has as it is currently defined in this memo.

4.1.1.  The Organizational Model

   It is beyond the scope of this memo to define the relations and
   interactions between different management domains.  The current CMOT
   architecture concerns itself only with the operations and
   characteristics of a single domain of management.  The extension of



Warrier & Besaw                                                [Page 13]

RFC 1095                          CMOT                        April 1989


   the mechanisms defined here to include multiple domains is left for
   further study.

4.1.2.  The Functional Model

   The CMOT architecture provides the foundation for carrying out
   management in the five functional areas (fault, configuration,
   performance, accounting, and security), but does not address
   specifically how any of these types of management are accomplished.
   It is anticipated that most functional requirements can be satisfied
   by CMIS.  The greatest impact of the functional requirements in the
   various areas will likely be on the definition of managed objects.

4.1.3.  The Information Model

   There are two different SMI specifications that are important to the
   CMOT architecture. The first is the SMI currently being defined by
   ISO [19].  This SMI is important to the CMOT approach because the ISO
   management protocol CMIP has been designed with the ISO model of
   management information in mind.  The second SMI of importance is the
   that defined by the IETF MIB working group for use in defining the
   Internet MIB [3].  This Internet SMI, which is loosely based on a
   simplified version of the ISO SMI, is important because the managed
   objects defined for TCP/IP networks to be used by CMOT are defined in
   terms of it.  Thus, in order to make the CMOT architecture complete,
   it will be necessary to show how the Internet SMI maps into CMIP in
   such a way as to enable it to convey the management information
   defined in the Internet MIB.  This is done in the section devoted to
   management information (section 5).

4.2.  Protocol Architecture

   The objective of the CMOT protocol architecture is to map the OSI
   management protocol architecture into the TCP/IP environment.  The
   model presented here follows the OSI model at the application layer,
   while using Internet protocols at the transport layer.  The ISO
   application protocols used for network management are ACSE, ROSE, and
   CMIP.  Instead of implementing these protocols on top of the ISO
   presentation, session, and transport layer protocols, the protocol
   data units (PDUs) for ACSE, ROSE, and CMIP are carried using the
   Internet transport protocols UDP [20] and TCP [21].  This is made
   possible by means of the lightweight presentation protocol defined in
   RFC 1085 [13] that maps ROSE and ACSE onto TCP/UDP/IP.  The use of
   Internet transport protocols is transparent to network management
   applications, since they are presented with real ISO services.






Warrier & Besaw                                                [Page 14]

RFC 1095                          CMOT                        April 1989


4.2.1.  The Lightweight Presentation Layer

   Given that it is desired to put ISO application protocols on top of
   TCP/IP, how is this best accomplished?  It is necessary somehow to
   fill the "gap" between the ISO protocols (ACSE and ROSE) and the
   Internet protocols (UDP and TCP).  Two basic approaches were
   considered.

   One possible approach [23] is to extend the ISO portion of the
   protocol stack down to the transport layer.  The ISO Transport
   Protocol Class 0 (TP 0) then uses TCP instead of an ISO network
   protocol.  Effectively, this treats TCP as a reliable network
   connection analogous to X.25.  This approach allows us to operate
   "standard" ISO applications over TCP regardless of their service
   requirements, since all ISO services are provided.  In this case,
   network management is just another such application.  The major
   drawback with this approach is that full ISO presentation, session,
   and transport layers are expensive to implement (both in terms of
   processing time and memory).

   Another approach is presented in RFC 1085.  Since the service
   elements required for network management (ACSE, ROSE, CMISE) do not
   require the use of full ISO presentation layer services, it is
   possible to define a "streamlined" presentation layer that provides
   only the services required.  This lightweight presentation protocol
   (LPP) allows the use of ISO presentation services over both TCP and
   UDP.  This approach eliminates the necessity of implementing ISO
   presentation, session, and transport protocols for the sake of doing
   ISO network management in a TCP/IP environment.  This minimal
   approach is justified because this non-ISO presentation protocol used
   is very small and very simple.  Thus, the LPP defined in RFC 1085
   provides a compact and easy to implement solution to the problem.
   The resulting CMOT protocol stack is shown in Figure 1.


















Warrier & Besaw                                                [Page 15]

RFC 1095                          CMOT                        April 1989


                   Manager                              Agent
           +-----------------------+           +-----------------------+
           |                       |           |                       |
           | +----+ +----+ +-----+ | <-------> | +----+ +----+ +-----+ |
           | |ACSE| |ROSE| |CMISE| |    CMIP   | |ACSE| |ROSE| |CMISE| |
           | +----+ +----+ +-----+ |           | +----+ +----+ +-----+ |
           |                       |           |                       |
           +-----------------------+           +-----------------------+
           |         LPP           |           |         LPP           |
           +-----------------------+           +-----------------------+
           |   TCP    |    UDP     |           |   TCP    |   UDP      |
           +-----------------------+           +-----------------------+
           |         IP            |           |         IP            |
           +-----------------------+           +-----------------------+
           |         Link          |           |         Link          |
           +-----------------------+           +-----------------------+
                      |                                   |
                      |                                   |
                      |                                   |
           =========================================================
                                  Network
           =========================================================

                     Figure 1.  The CMOT Protocol Architecture


   It is important to note that the presentation services provided by
   the LPP are "real" (but minimal) ISO presentation services [24].
   This provides a clear migration path to "full ISO" in the future.
   Such a migration would be accomplished by substituting ISO protocols
   for the Internet protocols TCP, UDP, and IP [25], and replacing the
   LPP with ISO presentation and session protocols.  No changes will be
   required in the ISO application layer protocols.  For this reason,
   investments in application development will be well preserved.

4.2.2.  The Quality of Transport Service

   The quality of transport service needed for network management
   applications is an issue that has caused much controversy, yet it has
   never been resolved.  There are two basic approaches: datagram-
   oriented and connection-oriented.  There are advantages and
   disadvantages to both of these two approaches. While the datagram-
   oriented approach is simple, requires minimal code space, and can
   operate under conditions where connections may not be possible, the
   connection-oriented approach offers data reliability and provides
   guaranteed and consistent service to the driving application.

   This memo does not take sides on this issue.  Rather it passes such



Warrier & Besaw                                                [Page 16]

RFC 1095                          CMOT                        April 1989


   resolution to the network management applications, which are
   ultimately the point where the requirements from the underlying
   service need to be determined.  As such, the CMOT protocol
   architecture provides both services.  The presentation layer service
   allows the application to select either high or low quality service
   for the underlying transport.  Depending on this choice, the LPP will
   use either UDP (low quality) or TCP (high quality) to establish the
   application association and carry the application data.  It is
   important, however, for the application to be aware of the quality of
   service that it is using: low quality means low quality!  The use of
   an unreliable transport like UDP necessarily puts more burden on the
   application.

4.3.  Proxy Management

   Proxy is a term that originated in the legal community to indicate an
   entity empowered to perform actions on behalf of another.  In our
   context, a proxy is a manager empowered to perform actions on behalf
   of another manager.  This may be necessary because the manager cannot
   communicate directly with the managed devices either for security or
   other administrative reasons or because of incompatible communication
   mechanisms or protocols.  In either case, the proxy assumes the agent
   role with respect to the requesting manager and the manager role with
   respect to the managed device.

   Some network elements, such as modems or bridges, may not be able to
   support CMIP and all the associated protocols.  In addition, such
   devices may not have Internet addresses.  Such devices are called
   "limited systems".  It may be possible to manage these devices using
   proprietary mechanisms or other standard protocols (such as the IEEE
   802.1 management protocol for managing bridges).  In cases where it
   is desirable to integrate the management of such devices with the
   overall CMOT management of an internet, it is necessary to use proxy
   management.  Some network elements that are not "limited systems" as
   described above may still benefit from the use of proxy management.
   If the management protocol supported by such a system is proprietary
   or some standard protocol other than CMIP (such as SNMP), then CMOT
   proxy management can be used to integrate the management of such
   systems.

   A proxy operates in the following manner.  When a CMOT manager wants
   to send a request to a managed device that it cannot communicate with
   directly, it routes the request to the proxy.  The proxy maps the
   CMIP request into the information schema understood by the managed
   device and sends the appropriate request to the managed device using
   the native management protocol of the device.  When the proxy
   receives the response from the managed device, it uses CMIP to return
   the information to the manager that made the original request.



Warrier & Besaw                                                [Page 17]

RFC 1095                          CMOT                        April 1989


   The use of proxy management can be largely transparent to the
   requesting manager, which appears to be exchanging information
   directly with the selected device.  The only thing that is known to
   the manager is that additional "instance" information is required to
   select a particular device managed by the proxy.  Each proxy may
   support many managed devices, using the "instance" information to
   multiplex CMIP requests and responses among them.  The mapping
   between a specific instance and an actual managed device is a local
   matter.  (The use of the CMIP Object Instance field to select a
   particular system to manage by proxy is explained below in section
   5.3.2.2.)

   A proxy may also serve as an "intermediate manager" in another less
   transparent sense.  The proxy manager may be requested to calculate
   summary statistics on information gathered from many different
   managed systems (e.g., the average number of PDUs transmitted or the
   distribution of PDUs transmitted over time).  The proxy may be
   requested to log events transmitted by the managed systems under its
   control and to send to the requesting manager only those events of
   specific types.  When this use of proxy management is made, the
   conceptual schema for managed objects known to both the requesting
   manager and proxy must include definitions of these aggregate managed
   objects (i.e., objects that do not belong to any one managed system).
   How the aggregate statistics would be calculated and logging
   performed based on information from the different devices managed by
   the proxy would be part of the definition of these aggregate managed
   objects.

4.4.  Directory Service

   RFC 1085 specifies the use of a minimal (or "stub") directory
   service.  It specifies how the service name for an OSI application
   entity is converted into an "application entity title." The
   application entity title is then mapped into a presentation address.
   The form of a service name, an application entity title, and a
   presentation address can be found in RFC 1085.

5.  Management Information

   The description of management information has two aspects.  First, a
   structure of management information (SMI) defines the logical
   structure of management information and how it is identified and
   described.  Second, the management information base (MIB), which is
   specified using the SMI, defines the actual objects to be managed.
   The purpose of this section is to show how CMIP is used in the CMOT
   architecture to convey information defined in the Internet MIB.





Warrier & Besaw                                                [Page 18]

RFC 1095                          CMOT                        April 1989


5.1.  The Structure of Management Information

   The SMI supplies the model for understanding management information,
   as well as templates and ASN.1 macros that can be used for defining
   actual management information.  The following sections discuss the
   ISO SMI, the Internet SMI, and a way of interpreting the Internet SMI
   in terms of the ISO SMI so that CMIP can be used to carry management
   information defined in terms of the Internet SMI.

5.1.1.  The ISO SMI

   The ISO SMI [19] is based on the abstraction of a "managed object"
   and the various kinds of relationships objects can be involved in.
   The following discussion does not purport to be a complete and
   accurate description of the latest ISO SMI work.  It is intended to
   be a clear presentation of the basic ISO SMI concepts essential for
   understanding the CMIP-specific interpretation of the Internet SMI
   presented in section 5.3.

5.1.1.1.  Managed Objects and Attributes

   Management Information is modeled using object-oriented techniques.
   All "things" in the network that are to be managed are represented in
   terms of managed objects.  A "managed object" is an abstraction (or
   logical view) for the purposes of network management of a
   "manageable" physical or logical resource of the network.  In this
   context, "manageable" means that a particular resource can be managed
   by using CMIP.  Examples of managed objects are protocol entities,
   modems, and connections.

   Each managed object belongs to a particular object class.  An "object
   class" represents a collection of managed objects with the same, or
   similar, properties.  A particular managed object existing in a
   particular network is defined as an "object instance" of the object
   class to which it belongs.  Thus, an object instance represents an
   actual realization of an object class (i.e., a managed object of a
   particular class bound to specific values).  An example of an object
   class is "transport connection." In an actual network, there are a
   number of managed objects (specific transport connections) that are
   instances of this class.  In summary, a managed object type, which is
   called an "object class," is the collection of all actual and
   potential instances of that type.

   Managed objects are fully defined by specifying the "attributes" or
   properties the object has, the CMIS operations that can be performed
   on the object (e.g., M-SET, M-CREATE) and any constraints on those
   operations, specific actions (e.g., self-test) that can be performed
   on the object, events that the object can generate, and information



Warrier & Besaw                                                [Page 19]

RFC 1095                          CMOT                        April 1989


   about various relationships the object may be involved in.  All of
   this information relevant to a managed object is typically provided
   by filling in an object template.

   Managed objects contain properties that are referred to as
   attributes.  Attributes are atomic items of information that can only
   be manipulated as a whole.  An example of an attribute is a counter
   providing a specific piece of information, such as the number of
   packets retransmitted.

   Each object class and attribute is assigned a unique identifier (an
   ASN.1 OBJECT IDENTIFIER) for purposes of naming by a registration
   authority.

5.1.1.2.  Management Information Hierarchies

   Managed objects participate in relationships with each other.  There
   are two relationships that are of particular importance for
   management information: the containment relationship and the
   inheritance relationship.  These relationships can be used to
   construct hierarchies of managed objects.  In addition, there is
   another hierarchy defined by the registration process for registering
   identifiers for object classes and attributes.

5.1.1.2.1.  The Registration Hierarchy

   The registration hierarchy is determined by the ASN.1 registration
   tree [5] for assigning OBJECT IDENTIFIERs.  An OBJECT IDENTIFIER is
   an administratively assigned name composed of a series of integers
   traversing a path from the root of the ASN.1 registration tree to the
   node or leaf to be identified.  For example, the sequence of integers
   { iso(1) standard(0) ips-osi-mips(9596) cmip(2) } (1.0.9596.2) can be
   used to uniquely identify the CMIP standard.  Each node of this tree
   has an associated registration authority that determines how numbers
   in the subtree defined by that node are allocated.  In the context of
   management, these OBJECT IDENTIFIERs are used for identifying object
   classes and attributes.  The registration hierarchy is not based on
   any particular relationship between managed objects or between
   managed objects and their attributes.  It is independent of both the
   inheritance and containment relationships described below.  Its
   purpose is simply to generate universally unique identifiers.

5.1.1.2.2.  The Containment Hierarchy

   The containment hierarchy is constructed by applying the relationship
   "is contained in" to objects and attributes.  Objects of one class
   may contain objects of the same or different class.  Objects may also
   contain attributes.  Attributes cannot contain objects or other



Warrier & Besaw                                                [Page 20]

RFC 1095                          CMOT                        April 1989


   attributes.  For example, objects of the class "transport entity" may
   contain objects of the class "transport connection"; an object of the
   class "management domain" may contain objects of the class "node." An
   object class that contains another object class is called the
   "superior" object class; an object class that is contained in another
   object class is called the "subordinate" object class.  The
   containment relationships that an object may participate in are part
   of the definition of the object class to which that managed object
   belongs.  All object classes (except the topmost) must have at least
   one possible superior in the containment tree.  The definition of a
   class may permit it to have more than one such superior.  However,
   individual instances of such a class are nevertheless contained in
   only one instance of a possible containing class.

   The containment hierarchy is important because it can be used for
   identifying instances of a managed object.  For example, assume there
   is an object class "domain" that contains an object class "node" that
   contains an object class "transport entity" that contains an object
   class "transport connection." A particular instance of a transport
   connection can be identified by the concatenation of "instance
   information" for each object class in the containment path: {
   domain="organization," node="herakles," transport entity=tp4,
   transport connection=<TSAP-AddressA, TSAP-AddressB> }.

   What constitutes appropriate "instance information" for each object
   class is part of the definition of that object class and is known as
   the "distinguished attribute(s)." A distinguished attribute is
   composed of an OBJECT IDENTIFIER naming the attribute and the value
   of the attribute.  For each object class, the distinguished
   attributes that differentiate instances of that class are
   collectively called the "relative distinguished name." A sequence of
   relative distinguished names (one for each class in the containment
   path) is the "distinguished name" of a managed object.  The example
   given above represents the distinguished name of a transport
   connection.  The containment hierarchy is sometimes referred to as
   the "naming tree", because it is used to "name" a particular instance
   of a managed object.

   The containment relationship also defines an existence dependency
   among its components; an object or attribute can "exist" only if the
   containing object also "exists." Deletion of an object may result in
   deletion of all objects and attributes contained within it.
   Alternately, depending on the definition of the managed object,
   deletion may be refused until all contained managed objects have been
   deleted.






Warrier & Besaw                                                [Page 21]

RFC 1095                          CMOT                        April 1989


5.1.1.2.3.  The Inheritance Hierarchy

   The inheritance hierarchy is constructed by applying the relationship
   "inherits properties of" to object classes.  An object class may
   inherit properties of another object class; refinement is obtained by
   adding additional properties.  In this relationship, the parent class
   is called the "superclass" and the inheriting class the "subclass."
   For example, the class "layer entity" may be a superclass of "network
   entity," which in turn is a superclass of "X.25 network entity."
   Attributes defined for "network entity" (e.g., the number of packets
   sent) are automatically defined for "X.25 network entity" without
   having to explicitly include them in the definition for the class
   "X.25 network entity." Thus, inheritance serves as a shorthand for
   defining object classes using object-oriented methodology.  Each
   class (except the topmost) has at least one superclass, but may have
   zero, one, or many subclasses.  Subclasses may in turn have further
   subclasses, to any degree.  A special object called "top" is the
   ultimate superclass.  It has no properties of its own.

   The inheritance hierarchy has no relevance to the naming of object
   instances.  It is useful only insofar as it leads to a manageable and
   extensible technique for the definition of object classes.

5.1.2.  The Internet SMI

   The Internet SMI [2] is designed to be a protocol-independent SMI
   that can be used with both SNMP and CMIP.  For this reason, it is
   necessary for any management protocol that uses this SMI to show how
   it is to be interpreted in a protocol-specific manner.  This is done
   for CMIP in this memo.

   The Internet SMI indicates both how to identify managed objects and
   how to define them.  The Internet SMI defines a registration subtree
   rooted at { iso(1) org(3) dod(6) internet(1) } for the sake of
   registering OBJECT IDENTIFIERs to be used for uniquely identifying
   managed objects.  The current Internet SMI specifies the format for
   defining objects in terms of an "object type" template and an
   associated OBJECT-TYPE ASN.1 macro.  An object type definition
   contains five fields: a textual name, along with its corresponding
   OBJECT IDENTIFIER; an ASN.1 syntax; a definition of the semantics of
   the object type; an access (read-only, read-write, write-only, or
   not-accessible); and a status (mandatory, optional, or obsolete).
   The current Internet SMI does not provide any mechanism for defining
   actions or events associated with a managed object.

   In describing management information, the current Internet SMI does
   not use the notions of "object class" and "attribute" found in the
   ISO SMI.  Only the concepts of "object type" and "object instance"



Warrier & Besaw                                                [Page 22]

RFC 1095                          CMOT                        April 1989


   are used.  The Internet SMI shows how to define object types; it
   leaves the specification of object instances as a protocol-specific
   matter.  The current Internet structure of management information is
   simpler and less rich than the corresponding ISO structure. The ISO
   SMI makes a distinction between simple "attributes," which can be
   viewed as "leaf objects" that are the lowest elements of the
   containment hierarchy, and composite "managed objects" that belong to
   an "object class" and have a structure associated with them (that is,
   can contain attributes).  The Internet SMI does not draw this
   distinction; both simple and composite "objects" are defined as
   "object types." What structure is associated with objects in the
   Internet SMI is defined through the deliberate attempt to structure
   the lower part of the Internet registration tree according to
   containment principles.  (Objects that are considered "attributes" of
   other containing objects are defined directly below them in the
   object registration tree.) This results in a certain lack of
   flexibility, since the registration hierarchy is implicitly used to
   define the containment hierarchy.  This means that the Internet SMI
   does not contain a mechanism for defining containment relationships
   that do not happen to coincide with the registration hierarchy.  In
   interpreting the Internet SMI for use with CMIP, it is necessary to
   overcome this limitation.

5.2.  The Management Information Base

   The Management Information Base (MIB) is a "conceptual repository of
   management information." It is an abstract view of all the objects in
   the network that can be managed.  Note that the MIB is conceptual in
   that it does not carry any implications whatsoever about the physical
   storage (main memory, files, databases, etc.) of management
   information.  The SMI provides the guidelines for defining objects
   contained in the MIB.

   The CMOT approach will use the Internet MIB based on the Internet SMI
   described above.  The first version of the Internet MIB, which is the
   product of the IETF MIB working group, is defined in RFC 1066 [3].
   It contains objects divided into eight groups: system, interfaces,
   address translation, IP, ICMP, TCP, UDP, and EGP.  In addition, the
   Internet SMI provides for future versions of the Internet MIB and a
   means for otherwise extending the MIB through the registration of
   managed objects under "private" and "experimental" branches of the
   object registration tree.  Appendix B provides a protocol-specific
   interpretation of the first version of the TCP/IP MIB defined in [3]
   so that it can be used with CMOT.  This interpretation is based on a
   straightforward mapping of the current Internet SMI to the ISO SMI
   (section 5.3).

   The initial version of the Internet MIB concentrates on defining



Warrier & Besaw                                                [Page 23]

RFC 1095                          CMOT                        April 1989


   objects associated with various Internet protocols.  It is expected
   that future versions of the Internet MIB and various extensions will
   provide a much richer set of objects to manage, including management
   information about a variety of network devices and systems.  Thus, an
   expanded MIB will allow wide-ranging and powerful management using
   the CMOT approach.

5.3.  An Interpretation of the Internet SMI

   In order to use CMIP to convey information defined in terms of the
   Internet SMI, it is necessary to show how object instances are
   specified and to provide the necessary structure for differentiating
   object class and attributes.  These objectives are both met by
   separating the containment hierarchy used for naming objects from the
   registration hierarchy and by imposing an "object class" structure on
   the Internet SMI.  Using the technique of imposing an object class
   structure does not replace or redefine the object definitions in the
   Internet MIB; it merely provides a necessary gloss or commentary on a
   MIB defined in terms of the Internet SMI.  For example, Appendix B
   references the "object type" definitions found in [3], but imposes
   additional structure on them.

   This object class definition derives from a simplified version of the
   OBJECT-CLASS macro defined in the ISO SMI [19].  The more complex
   definition is not needed for present purposes.  (The object class
   definition presented here could be extended in the future to show
   what actions and events are associated with a managed object.) The
   object class definition has the following fields:

   OBJECT CLASS:
   ------------
      A textual name, termed the OBJECT CLASS DESCRIPTOR, for the object
      class, along with its corresponding OBJECT IDENTIFIER.

   Definition:
      A textual description of the object class.

   Subclass Of:
      The OBJECT CLASS DESCRIPTOR of the object class that is the
      superclass of this object class. This field is used for indicating
      the inheritance relationship.

   Superiors:
      A list of OBJECT CLASS DESCRIPTORs of the possible superior object
      classes of this object class. This field is used for indicating
      the containment relationship.





Warrier & Besaw                                                [Page 24]

RFC 1095                          CMOT                        April 1989


   Names:
      A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
      the distinguished attributes of this object class. (The OBJECT-
      TYPE macro is defined in RFC 1065). Attributes listed here will
      normally be present in the Attribute field of the object class
      definition.  This field is used for indicating what attributes
      must be present in the relative distinguished name that indicates
      an instance of this object class.

   Attributes:
      A list of OBJECT DESCRIPTORs identifying the OBJECT TYPES that are
      attributes of this object class. (The OBJECT-TYPE macro is defined
      in RFC 1065). This field is used for indicating the attributes
      that are contained in this object class.

      This object class definition satisfies our objectives for
      interpreting the Internet SMI for use by CMIP.  The Attributes
      field shows what attributes are contained in this object class;
      this makes the necessary distinction between object classes and
      attributes required by CMIP.  Instead of referencing an
      "attribute" def inition (as is done in the ISO SMI), the
      Attributes field references the "object type" definition found in
      RFC 1065 and used to define the Internet-standard MIB in RFC 1066.
      The name, syntax, and access information required for attributes
      is contained in the "object type" definition.  Two things are
      required for specifying an instance of a managed object: a
      containment relationship determining a sequence of object classes
      and a means for specifying the distinguished attributes for an
      object class.  The Superiors field makes the containment
      relationship explicit; it is no longer merely a function of the
      registration tree.  The Names field makes it possible to indicate
      the distinguished attributes for an object class required for
      giving instance information.  Thus, the object class definition
      makes it possible to specify an object instance using CMIP.

5.3.1.  Object Class and Attributes

   The mapping of management information to the CMIS parameters Managed
   Object Class and Attribute Identifier List now becomes apparent.

5.3.1.1.  Object Class

   The CMIS Managed Object Class parameter is the OBJECT IDENTIFIER
   assigned to the particular object class.  For example, the Managed
   Object Class for the object class "ip" (as defined in Appendix B) is

        { mib 4 } = 1.3.6.1.2.1.4.




Warrier & Besaw                                                [Page 25]

RFC 1095                          CMOT                        April 1989


5.3.1.2.  Attribute Identifier

   The CMIS Attribute Identifier List parameter is a list of Attribute
   Identifiers.  An Attribute Identifier can be either global or local.
   If it is global, then it is the OBJECT IDENTIFIER assigned to the
   attribute (i.e., "object type") that is being indicated.  For
   example, the global Attribute Identifier for the attribute
   "ipForwarding" (as defined in [3]) is

        { ip 1 } = 1.3.6.1.2.1.4.1.

   If the Attribute Identifier is local, it is an integer that is the
   last component in the OBJECT IDENTIFIER identifying the object.  For
   ipForwarding, the local Attribute Identifier is 1.  In the case where
   the local identifier is used, the leading components of the OBJECT
   IDENTIFIER for the attribute must be the OBJECT IDENTIFIER of the
   containing object class.  This is true for the interpreted Internet
   MIB defined in Appendix B, but may not be true generally.  The local
   identifier is intended to be interpreted relative to the Managed
   Object Class field of the CMIP PDU.  When a local Attribute
   Identifier is encountered in a CMIP PDU, the global form of the
   identifier is formed by prepending the OBJECT IDENTIFIER in the
   Managed Object Class field to the local identifier.  This is valid
   only when scoping is not used (i.e., scoping is "baseObject").  If
   scoping is used, then the global form of the Attribute Identifier
   must be used instead of the local form.

5.3.2.  Management Information Hierarchies

   The following sections show how the three management information
   hierarchies are to be understood for the interpreted Internet SMI.

5.3.2.1.  The Registration Hierarchy

   The registration hierarchy is the global object registration tree
   described in [2].  It is used merely for assigning identifiers for
   object classes and attributes (i.e., "object types" in RFC 1065).

5.3.2.2.  The Containment Hierarchy

   As described above, the containment hierarchy is used to specify an
   object instance.  The Names field of the object class definition
   contains the distinguished attributes for the object class.  The
   OBJECT IDENTIFIER naming the "attribute" together with its value is
   called an attribute value assertion.  A set of attribute value
   assertions (one for each distinguished attribute) is the relative
   distinguished name associated with that object class.  The sequence
   of relative distinguished names for each of the object classes in the



Warrier & Besaw                                                [Page 26]

RFC 1095                          CMOT                        April 1989


   containment hierarchy to which a managed object belongs is the
   distinguished name of the object.  An object instance is fully
   specified by a distinguished name.

   Let us take a concrete example from Appendix B.  How would we
   represent an instance of an entry in the IP routing table?  We begin
   by examining the object class in question (ipRouteEntry) and use the
   Superiors field to find the superior class in the containment
   hierarchy (ipRoutingTable).  This process continues until we
   construct the following containment path of object classes: system,
   ip, ipRoutingTable, ipRouteEntry.  Now for each of these object
   classes, we inspect the Names field to find the distinguished
   attribute for that object class.  If no Names field is present (as is
   the case for "ip" and "ipRoutingTable"), then no instance information
   is required at that level.  Both "system" and "ipRouteEntry" have
   Name fields to show what information is expected at that level.  With
   this information, we can construct the following distinguished name
   specifying an instance of an IP routing table entry:


                  baseManagedObjectInstance {
                     distinguishedName {
                        relativeDistinguishedName {    -- system
                           attributeValueAssertion {
                              attributeType { cmotSystemID }
                              attributeValue "gateway1.acme.com"
                           }
                        },
                        relativeDistinguishedName {    -- ipRouteEntry
                           attributeValueAssertion {
                              attributeType { ipRouteDest }
                              attributeValue 10.0.0.51
                           }
                        }
                     }
                  }


   If the system instance information is not present, then it is assumed
   to be the system with which the management association is established
   (i.e., the system receiving the request).

   Note that the object instance tree can contain components of the
   distinguished name that are outside the managed system (node).  This
   enables referencing of objects across management domains (there could
   be an object class "domain") and across a collection of nodes.  In a
   network where several intermediate managers may be involved in a
   request, each intermediate manager can use the "system" portion of



Warrier & Besaw                                                [Page 27]

RFC 1095                          CMOT                        April 1989


   the name to determine where to send a request or result.  This
   technique of naming treats each intermediate managing system as a
   proxy manager.  The proxy manager resolves the address of the next
   node in the chain and may use a different protocol to transfer the
   request or result.  Thus, the "system" instance information can be
   used to name devices being managed by proxy.

5.3.2.3.  The Inheritance Hierarchy

   The Internet SMI does not use the inheritance relationship. The
   "Subclass Of" field is present in the object class definition to show
   how the inheritance relationship would be represented and to allow
   for future extensibility.  It is not used for any of the object
   classes defined in Appendix B.

5.4.  Scoping, Filtering, and Synchronization

   Within some services, CMIS provides additional capabilities that are
   related to the SMI.  These are the scoping, filtering,
   synchronization, and linked-reply facilities.  The presence of these
   facilities are indicated by the Multiple Object Selection Functional
   Unit defined in CMIS [11].

   These facilities provide the manager with the ability to operate on a
   collection of managed objects, rather than a single object.  The
   selection of multiple objects occurs in two phases: scoping and
   filtering.  Scoping is used to identify the managed objects to which
   a filter is to be applied.  Then filtering is used to select a subset
   of managed objects that satisfy certain conditions.  If scoping is
   not used, only the "base" managed object indicated by the CMIS
   Managed Object Class parameter is implied.  An example of the use of
   scoping and filtering for selecting a particular managed object (a
   table entry) is given in one of the sample protocol exchanges found
   in Appendix C.

5.4.1.  Scoping

   Scoping is meant to be understood in terms of the containment
   hierarchy.  A position at a certain level of the containment tree is
   defined by the CMIS Managed Object Class parameter.  The CMIS Scope
   parameter is then interpreted relative to this "base" managed object
   (defined by both object class and object instance).  The Scope
   parameter can be used to select the base object alone, all managed
   objects in the entire subtree (of the containment tree) below the
   base object, or all managed objects in the "n"th level (n = 1, 2,
   3,...) below the base object.





Warrier & Besaw                                                [Page 28]

RFC 1095                          CMOT                        April 1989


5.4.2.  Filtering

   Within the objects selected as a result of the scope parameter, it is
   possible to further refine the selection of managed objects through
   the use of filtering.  Filtering provides the ability to select a
   subset of these objects based on conditions applied to attributes
   (e.g., IP routing table entries with the "ipRouteAge > 100") and
   logical operations (and, or, not).

5.4.3.  Synchronization

   When multiple managed objects have been selected using scoping and
   filtering, the question of synchronization across object instances
   (such as multiple IP routing table entries) arises.  The two possible
   choices are "best effort" and "atomic." If "best effort"
   synchronization is selected, the failure to apply an operation (e.g.,
   M-SET) to one instance of an object does not affect the effort to
   apply this operation to other instances of the object.  If "atomic"
   synchronization is selected, then the operation is either performed
   on all object instances selected or none.  The default
   synchronization is best effort.

5.4.4.  Linked Replies

   If the reply to a single request for a set of managed objects results
   in more than one managed object being returned, all of these managed
   objects cannot be returned together in a single CMIP response PDU.
   The reason for this is that the structure of the CMIP response PDU
   only has a single field for containing object instance information.
   Since each managed object has its own instance information, each
   managed object must be returned in a separate CMIP PDU.  In such a
   case, the CMIP Linked Reply PDU is used.  The Linked Reply PDU
   provides a means of associating each of the multiple replies with the
   original request that generated them.  Thus, a single CMIP Get
   Request PDU that uses scoping and filtering would result in zero or
   more CMIP Linked Reply PDUs being returned before a final CMIP Get
   Result PDU.

   A linked reply can also be used to segment a CMIP response pertaining
   to a single managed object.  This would only be necessary if UDP is
   being used as the underlying transport and it is not possible to
   return all the information requested about the managed object in a
   single response PDU subject to the size limitations described in
   section 10.2.

5.5.  Accessing Tables

   This section explains how to use the interpreted Internet SMI and MIB



Warrier & Besaw                                                [Page 29]

RFC 1095                          CMOT                        April 1989


   to access tables.

5.5.1.  Accessing Whole Tables

   A whole table is accessed by specifying the object class of the
   table, indicating a scoping level of one, and not providing an
   attribute identifier list. The CMIS standard [11] specifies that if
   the attribute identifier parameter is not present, then all attribute
   identifiers are assumed.  The following CMIS parameters would be used
   to return the entire TCP connection table:

        Object Class: { tcpConnTable }
        Object Instance: "empty" (unless proxy management is used)
        Scope: oneLevel(1)
        Filter: not present
        Attribute Identifier List: not present

   By scoping one level below "tcpConnTable," all managed objects of the
   class "tcpConnEntry" are selected.  (The object class "tcpConnEntry"
   is the only object class one level below the object class
   "tcpConnTable" in the containment hierarchy.) The absence of an
   attribute identifier list signals that all attributes of the managed
   object are to be returned (i.e., all fields of the TCP connection
   table entry).

   In reply to this request, each entry of the table will be returned in
   a separate CMIP PDU (either a Linked Reply PDU or a Get Result PDU).
   Each reply CMIP PDU will specify the Object Class "tcpConnEntry" and
   the appropriate Object Instance information for that entry, as well
   as an Attribute List giving the values of each of the fields of the
   table entry.

5.5.2.  Accessing Table Entries

   An entire table entry is accessed by specifying the object class of
   the table entry, providing a distinguished name specifying the
   instance of the table entry, and not providing an attribute
   identifier list. As seen above, the absence of the attribute
   identifier list parameter indicates that all attributes are assumed.
   The absence of a scope parameter indicates that the base managed
   object class is intended.  The following CMIS parameters would be
   used to return the entire IP routing table entry for which the field
   "ipRouteDest" has the value 10.0.0.51:

        Object Class: { ipRouteEntry }
        Object Instance: { ipRouteDest, 10.0.0.51 }
        Scope: not present
        Filter: not present



Warrier & Besaw                                                [Page 30]

RFC 1095                          CMOT                        April 1989


        Attribute Identifier List: not present

   The result is returned in a single CMIP Get Result PDU with an
   attribute list consisting of all of the attributes (i.e., fields) of
   the table entry and their corresponding values.

   If the object class field refers to a table entry and no instance
   information is provided to select a particular entry, then a
   "noSuchObjectInstance" CMIP error should be returned.










































Warrier & Besaw                                                [Page 31]

RFC 1095                          CMOT                        April 1989


                       Part II: Protocol Agreements

6.  CMOT Protocol Overview

   This part of the document is a specification of the protocols of the
   CMOT architecture. Contained herein are the agreements required to
   implement interoperable network management systems using these
   protocols.  The protocol suite defined by these implementors'
   agreements will facilitate communication between equipment of
   different vendors, suppliers, and networks.  This will allow the
   emergence of powerful multivendor network management based on ISO
   models and protocols.

   The choice of a set of protocol standards together with further
   agreements needed to implement those standards is commonly referred
   to as a "profile." The selection policy for the CMOT profile is to
   use existing standards from the international standards community
   (ISO and CCITT) and the Internet community.  Existing ISO standards
   and draft standards in the area of OSI network management form the
   basis of this CMOT profile.  Other ISO application layer standards
   (ROSE and ACSE) are used to support the ISO management protocol
   (CMIP).  To ensure interoperability, certain choices and restrictions
   are made here concerning various options and parameters provided by
   these standards.   Internet standards are used to provide the
   underlying network transport.  These agreements provide a precise
   statement of the implementation choices made for implementing ISO
   network management standards in TCP/IP-based internets.

   In addition to the Netman working group, there are at least two other
   bodies actively engaged in defining profiles for interoperable OSI
   network management: the National Institute of Science and Technology
   (NIST) Network Management Special Interest Group (NMSIG) and the OSI
   Network Management Forum.  Both of these groups are similar to the
   Netman working group in that they are each defining profiles for
   using ISO standards for network management.  Both differ in that they
   are specifying the use of underlying ISO protocols, while the Netman
   working group is concerned with using OSI management in TCP/IP
   networks.  In the interest of greater future compatibility, the
   Netman working group has attempted to make the CMOT profile conform
   as closely as possible to the ongoing work of these two bodies.

6.1.  The CMOT Protocol Suite

   The following seven protocols compose the CMOT protocol suite: ISO
   ACSE, ISO DIS ROSE, ISO DIS CMIP, the lightweight presentation
   protocol (LPP), UDP, TCP, and IP.  The relation of these protocols to
   each other is briefly summarized in Figure 2.




Warrier & Besaw                                                [Page 32]

RFC 1095                          CMOT                        April 1989


                 +----------------------------------------------+
                 |       Management Application Processes       |
                 +----------------------------------------------+

                             +-------------------+
                             |       CMISE       |
                             | ISO DIS 9595/9596 |
                             +-------------------+

                 +------------------+       +--------------------+
                 |        ACSE      |       |        ROSE        |
                 | ISO IS 8649/8650 |       | ISO DIS 9072-1/2   |
                 +------------------+       +--------------------+

                 +-----------------------------------------------+
                 |     Lightweight Presentation Protocol (LPP)   |
                 |                   RFC 1085                    |
                 +-----------------------------------------------+

                 +------------------+       +--------------------+
                 |       TCP        |       |        UDP         |
                 |     RFC 793      |       |      RFC 768       |
                 +------------------+       +--------------------+

                 +-----------------------------------------------+
                 |                     IP                        |
                 |                   RFC 791                     |
                 +-----------------------------------------------+

                      Figure 2.  The CMOT Protocol Suite

6.2.  Conformance Requirements

   A CMOT-conformant system must implement the following protocols:
   ACSE, ROSE, CMIP, LPP, and IP.  A conformant system must support the
   use of the LPP over either UDP or TCP.  The use of the LPP over both
   UDP and TCP on the same system may be supported.  A conformant system
   need not support all CMIS operations.  A conformant system must,
   however, support at least one of the functional unit groups
   (indicating a set of supported services) defined in section 7.1.3.
   The service and protocol selections are described in greater detail
   in the following sections.

6.3.  Abstract Syntax Notation

   The abstract syntax notation for all of the application service
   elements of the CMOT protocol suite is Abstract Syntax Notation One
   (ASN.1) [5].  The LPP is also defined using ASN.1.  The basic



Warrier & Besaw                                                [Page 33]

RFC 1095                          CMOT                        April 1989


   encoding rules used for ASN.1 are specified in [6].  Both definite-
   length and indefinite-length encodings are expressly permitted.

7.  Common Management Information Service Element

   The Common Management Information Service Element (CMISE) is
   specified in two ISO documents.  The service definition for the
   Common Management Information Service (CMIS) is given in ISO DIS
   9595-2 [11].  The protocol specification for the Common Management
   Information Protocol (CMIP) is found in ISO DIS 9596-2 [12].

7.1.  CMIS Services

7.1.1.  CMIS Services Overview

   All of the CMIS services listed in Table 1 are allowed with the CMOT
   approach: M-INITIALISE, M-TERMINATE, M-ABORT, M-EVENT-REPORT, M-GET,
   M-SET, M-ACTION, M-CREATE, and M-DELETE.  The specific services
   supported by a system will be determined by the functional unit group
   or groups to which a system belongs.

7.1.2.  Functional Units

   The CMIS services supported are designated in terms of functional
   units [11].  Each functional unit corresponds to the invoker or
   performer aspect of a particular service.  (The terms "invoker" and
   "performer" are taken from ROSE and refer to the caller of and
   responder to a remote operation, respectively.) The "stand alone"
   functional units associated with each of the management services are
   given in Table 2 as functional units 0-17.  The number following the
   name of each functional unit in the table is defined by CMIP [12] to
   identify that particular functional unit.  The functional units are
   used by the CMISE-service-user at the time of association
   establishment to indicate which services it is willing to support.

















Warrier & Besaw                                                [Page 34]

RFC 1095                          CMOT                        April 1989


   +---------------------------------+------------------------+------+
   | Functional Unit                 | Service Primitives     | Mode |
   +---------------------------------+------------------------+------+
   | conf. event report invoker(0)   | M-EVENT-REPORT Req/Conf| C    |
   | conf. event report performer(1) | M-EVENT-REPORT Ind/Rsp | C    |
   | event report invoker(2)         | M-EVENT-REPORT Req     | U    |
   | event report performer(3)       | M-EVENT-REPORT Ind     | U    |
   | confirmed get invoker(4)        | M-GET Req/Conf         | N/A  |
   | confirmed get performer(5)      | M-GET Ind/Rsp          | N/A  |
   | confirmed set invoker(6)        | M-SET Req/Conf         | C    |
   | confirmed set performer(7)      | M-SET Ind/Rsp          | C    |
   | set invoker(8)                  | M-SET Req              | U    |
   | set performer(9)                | M-SET Ind              | U    |
   | confirmed action invoker(10)    | M-ACTION Req/Conf      | C    |
   | confirmed action performer(11)  | M-ACTION Ind/Rsp       | C    |
   | action invoker(12)              | M-ACTION Req           | U    |
   | action performer(13)            | M-ACTION Ind           | U    |
   | confirmed create invoker(14)    | M-CREATE Req/Conf      | N/A  |
   | confirmed create performer(15)  | M-CREATE Ind/Rsp       | N/A  |
   | confirmed delete invoker(16)    | M-DELETE Req/Conf      | N/A  |
   | confirmed delete performer(17)  | M-DELETE Ind/Rsp       | N/A  |
   | multiple reply(18)              | Linked Identification  | N/A  |
   | multiple object selection(19)   | Scope, Filter, Sync.   | N/A  |
   | extended service(20)            | Extended Presentation  | N/A  |
   +---------------------------------+------------------------+------+
    C = confirmed, U = non-confirmed, N/A = not applicable

                          Table 2.  Functional Units

   In addition to the stand alone functional units, there are three
   additional functional units.  If any of these additional functional
   units are selected, then at least one of the stand alone functional
   units must be selected.  The multiple reply functional unit makes
   available the use of the linked identification parameter in the
   selected stand alone functional units.  This makes possible the use
   of linked reply (multiple CMIP PDU responses to a single request).
   The multiple object selection functional unit makes available the use
   of the scope, filter, and synchronization parameters in the selected
   stand alone functional units.  If the multiple object selection
   functional unit is selected, then the multiple reply functional unit
   must also be selected.  The extended services functional unit makes
   available presentation layer services in addition to the P-DATA
   service.  Selecting this functional unit has no effect in the context
   of CMOT, since the lightweight presentation layer provides only
   minimal ISO presentation services.






Warrier & Besaw                                                [Page 35]

RFC 1095                          CMOT                        April 1989


7.1.3.  Functional Unit Groups

   In order to assist in the reduction of code size and complexity for
   different types of devices, a number of "functional unit groups" have
   been defined.  Each of these groups indicates a set of services
   defined for either a manager or an agent.  The "negotiation"
   concerning which functional unit groups are supported is done by
   means of the Functional Units parameter of the M-INITIALISE service
   (see section 7.1.4.1).  There are five functional unit groups for
   managers: Event Monitor, Monitoring Manager, Simple Manager,
   Controlling Manager, and Full Manager.  Each functional unit group is
   a superset of the preceding group.  There are five functional unit
   groups for agents: Event Sender, Monitored Agent, Simple Agent,
   Controlled Agent, and Full Agent.  Again, each functional unit group
   is a superset of the preceding group.  The operations supported for
   each functional unit group are summarized in Table 3.


   +--------------------+------+-----+-----+-------+------+-----+------+
   |                    |Event | Get | Set |Create/|Action|Mult.|Mult. |
   |Functional Unit     |Report|     |     |Delete |      |Reply|Object|
   |Groups              |      |     |     |       |      |     |Select|
   +--------------------+------+-----+-----+-------+------+-----+------+
   | 1. Event Monitor   | U    | no  | no  | no    | no   | no  | no   |
   | 2. Event Sender    | U    | no  | no  | no    | no   | no  | no   |
   | 3. Monitoring Mgr. | U    | yes | no  | no    | no   | no  | no   |
   | 4. Monitored Agent | U    | yes | no  | no    | no   | no  | no   |
   | 5. Simple Manager  | U    | yes | C   | no    | no   | yes | no*  |
   | 6. Simple Agent    | U    | yes | C   | no    | no   | yes | no*  |
   | 7. Controlling Mgr.| U    | yes | U/C | yes   | no   | yes | yes  |
   | 8. Controlled Agent| U    | yes | U/C | yes   | no   | yes | yes  |
   | 9. Full Manager    | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
   |10. Full Agent      | U/C  | yes | U/C | yes   | U/C  | yes | yes  |
   +--------------------+------+-----+-----+-------+------+-----+------+
    C = confirmed, U = non-confirmed
    * Simple Managers and Agents must support "oneLevel" scoping for all
      and only those cases where it is required to access a whole table
      and may support synchronization other than "best effort"; no support
      for filtering is required.

                       Table 3.  Functional Unit Groups


   A conformant system must support at least one of these functional
   unit groups.  A system may support both a manager group and an agent
   group.  A system only needs to implement the services and service
   primitives required for the groups that it supports.  In addition, a
   system may support services that are not required by any group that



Warrier & Besaw                                                [Page 36]

RFC 1095                          CMOT                        April 1989


   it supports.

7.1.4.  M-INITIALISE Parameters

   The M-INITIALISE service is provided by the ACSE A-ASSOCIATE service.
   The parameters for the M-INITIALISE service are defined in [11] and
   summarized in Table 4.


                 +-------------------+-----------+-----------+
                 | Parameter Name    | Req/Ind   | Rsp/Conf  |
                 +-------------------+-----------+-----------+
                 | Functional Units  | Mandatory | Mandatory |
                 | User Information  | Optional  | Optional  |
                 | Access Control    | Optional  | Optional  |
                 +-------------------+-----------+-----------+

                       Table 4. M-INITIALISE Parameters


   Notice that the further agreement has been made that the Functional
   Units parameter is mandatory at all times.  The M-INITIALISE
   parameters are conveyed as ACSE user information in the ACSE request
   PDU.

7.1.4.1.  Functional Units

   The exchange of functional units between the initiating CMISE-
   service-user and the responding CMISE-service-user is required.  This
   allows the CMIS-service-users to inform each other which functional
   units are supported.  CMIP [12] defines a 21-bit BIT STRING to
   communicate which functional units are supported.  A functional unit
   is supported if the corresponding bit in this bit string is one.  The
   correspondence between functional units and functional unit groups is
   given in Table 5.  The left column gives the functional unit
   corresponding to a particular bit position. The numbers along the top
   of the table indicate the functional unit group (the numbers of the
   functional unit groups are given in Table 3).  The various columns
   indicate the value of each bit for a particular functional unit
   group.











Warrier & Besaw                                                [Page 37]

RFC 1095                          CMOT                        April 1989


+------------------------------+---+---+---+---+---+---+---+---+---+---+
|Functional Unit               | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10|
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|conf. event report invoker(0) | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|conf. event report perf.(1)   | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|event report invoker(2)       | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|event report performer(3)     | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get invoker(4)      | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed get performer(5)    | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 | 1 |
|confirmed set invoker(6)      | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 | 0 |
|confirmed set performer(7)    | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 1 |
|set invoker(8)                | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|set performer(9)              | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed action invoker(10)  | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|confirmed action performer(11)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|action invoker(12)            | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
|action performer(13)          | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
|confirmed create invoker(14)  | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed create performer(15)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|confirmed delete invoker(16)  | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
|confirmed delete performer(17)| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 |
|multiple reply(18)            | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
|multiple object selection(19) | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
|extended service(20)          | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
|                              | M | A | M | A | M | A | M | A | M | A |
+------------------------------+---+---+---+---+---+---+---+---+---+---+
        1 = supported, 0 = not supported, M = manager, A = agent

                     Table 5.  Functional Unit Group Values


   The "negotiation" using functional units proceeds as follows.  The
   initiating CMISE-service-user (manager or agent) sends the functional
   units representing the functional unit group to which it belongs.
   The responding CMISE-service-user sends the functional units
   representing the functional unit group to which it belongs.  (If an
   application process belongs to both a manager and an agent functional
   unit group, then both functional unit groups are indicated using the
   same functional unit bit string.) If the functional unit groups
   supported by the two application entities do not allow meaningful
   communication, then either entity may refuse the association.
   Meaningful communication is defined as the ability of the entity to
   invoke or perform at least one CMIS operation supported by the other
   entity (i.e., some "complementary" set of functional units exists).
   After an association has been established, a system must provide the
   proper response for functional units that it has indicated it can
   support and should gracefully refuse other requests in accordance



Warrier & Besaw                                                [Page 38]

RFC 1095                          CMOT                        April 1989


   with the protocol.

7.1.4.2.  User Information

   The User Information parameter is optional.  No entity is required to
   send this parameter, but all entities are expected to tolerate
   receipt of it.

   One possible use of the User Information parameter is to convey
   information describing MIB extensions supported by the manager or
   agent.  This can be viewed as a further way of refining the
   application context.  The mechanism for doing this is not defined at
   this time.

7.1.4.3.  Access Control

   The CMIS M-INITIALISE Access Control parameter is optional.  Access
   control is supported on a per association basis using ACSE.  It is
   recommended (but not required) that the access control parameter be
   used for each A-ASSOCIATE request (via M-INITIALISE).

   Access control is also possible on a per request basis with the CMIS
   Access Control parameter. This parameter might be used to implement
   security similar to the community access rights mechanism provided by
   SNMP [4].  It is expected that the Access Control parameter will be
   used to implement the standard TCP/IP authentication mechanism once
   this has been defined.

7.2.  Supporting Services

   The M-INITIALISE, M-TERMINATE, and M-ABORT services assume the use of
   ACSE.  The following ACSE services are required: A-ASSOCIATE, A-
   RELEASE, A-ABORT, and A-P-ABORT.  The rest of the CMIP protocol uses
   the RO-INVOKE, RO-RESULT, RO-ERROR, and RO-REJECT services of ROSE.

7.3.  CMIP Agreements

   The following sections contain specific CMIP agreements in addition
   to those specified in the CMIP standard [12].

7.3.1.  Invoke Identifier

   It is required that there be a unique invoke identifier (present in
   the ROSE PDU) for successive invocations on the same association.
   The invoke identifier is provided by the invoking CMISE-service-user.
   Invoke identifiers should increase monotonically during the lifetime
   of an association.  Semantically, the invoke identifier is a Counter
   as defined in [2].  Unique identifiers will allow the detection of



Warrier & Besaw                                                [Page 39]

RFC 1095                          CMOT                        April 1989


   lost and duplicate requests.

7.3.2.  Object Class

   The object class field of all CMIP PDUs shall be limited to the
   "globalForm" choice:


           ObjectClass ::=
                CHOICE {
                     globalForm    [0] IMPLICIT OBJECT IDENTIFIER
                }


7.3.3.  Object Instance

   The object instance field of all CMIP PDUs is limited to the
   "distinguishedName" choice:


           ObjectInstance ::=
                CHOICE {
                     distinguishedName  [2] IMPLICIT DistinguishedName
                }


   The definition for DistinguishedName is imported from CCITT X.500 and
   ISO DIS 9594-2 [26]:

   DistinguishedName ::= RDNSequence
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   RelativeDistinguishedName ::= SET OF AttributeValueAssertion

   The definition for AttributeValueAssertion is contained in CMIP [12]:

   AttributeValueAssertion ::= SEQUENCE { AttributeId, AttributeValue }
   AttributeId ::=
        CHOICE {
              globalId   [0] IMPLICIT OBJECT IDENTIFIER
              localId    [1] IMPLICIT INTEGER
        }
   AttributeValue ::= ANY DEFINED BY attributeId

   Those attributes to be used as the distinguished attributes of a
   managed object are defined at the time of registration of the object
   class and are identified in the NAMES clause of the OBJECT-CLASS
   macro.




Warrier & Besaw                                                [Page 40]

RFC 1095                          CMOT                        April 1989


   When there is no instance information to convey about a managed
   object, then the following "empty" object instance shall be used: The
   "distinguishedName" choice of ObjectInstance shall be an RDNSequence
   consisting of a SEQUENCE of one RelativeDistinguishedName. That
   RelativeDistinguishedName shall be an empty SET of
   AttributeValueAssertions.

7.3.4.  Access Control

   The access control parameter is optional.  The receipt of this
   parameter must be tolerated (i.e., gracefully accepted), but a
   receiving entity is free to ignore this information.  The Access
   Control field is defined in [12] as EXTERNAL.  Until a more
   sophisticated access control mechanism is defined, simple
   authentication can be accomplished by using an unencrypted password
   in the access control field.  The definition of this EXTERNAL is the
   same as that for the ACSE Access Control field (section 8.3.2).

7.3.5.  Synchronization

   Support for "best effort" synchronization is required.  Atomic
   synchronization may also be supported, but is not required.

7.3.6.  Scope

   Scoping is supported if the multiple object selection functional unit
   is selected.  If scoping is supported, all values of the scope field
   shall be supported.

7.3.7.  Filter

   Filtering is supported if the multiple object selection functional
   unit is selected.  If filtering is supported, it is not required that
   all features of filtering be supported.  The following are the
   minimal filtering requirements for any system that supports
   filtering.  In the CMIP field CMISFilter, at least two instances of
   the binary operators ("and," "or") must be supported.  Support for
   additional instances of these operators is not required.  Double
   "not" need not be supported.  In FilterItem, the arithmetic
   operations ("equality", "greaterOrEqual," "lessOrEqual") must be
   supported.  The "present" choice of FilterItem must also be
   supported.  It is not required to support string operations (namely,
   the "substrings" choice of the FilterItem type).  Thus, the minimal
   requirements for filtering yield this restricted definition of
   FilterItem:






Warrier & Besaw                                                [Page 41]

RFC 1095                          CMOT                        April 1989


              FilterItem ::=
                   CHOICE {
                        equality       [0] AttributeValueAssertion,
                        greaterOrEqual [2] AttributeValueAssertion,
                        lessOrEqual    [3] AttributeValueAssertion,
                        present        [4] AttributeID
                   }


7.3.8.  Attribute Identifier

   Both choices for the CMIP AttributeId field are allowed:


              AttributeId ::=
                   CHOICE {
                        globalId  [0] IMPLICIT OBJECT IDENTIFIER,
                        localId   [1] IMPLICIT INTEGER
                   }


   The "globalId" form of AttributeId is required if scoping is used
   (i.e., the value of the scope field is other than "baseObject").

7.3.9.  Event Type Identifier

   Both choices for the CMIP EventTypeId field are allowed:


              EventTypeId ::=
                   CHOICE {
                        globalId  [6] IMPLICIT OBJECT IDENTIFIER,
                        localId   [7] IMPLICIT INTEGER
                   }


7.3.10.  Action Type Identifier

   Both choices for the CMIP ActionTypeId field are allowed:


              ActionTypeId ::=
                   CHOICE {
                        globalId  [2] IMPLICIT OBJECT IDENTIFIER,
                        localId   [3] IMPLICIT INTEGER
                   }





Warrier & Besaw                                                [Page 42]

RFC 1095                          CMOT                        April 1989


   The "globalId" form of ActionTypeId is required if scoping is used
   (i.e., the value of the scope field is other than "baseObject").

7.3.11.  Time Fields

   The "eventTime" field of the m-EventReport Invoke PDU and the m-
   EventConfirmedReport Invoke PDU must be present.

   The "currentTime" field of the following PDUs must be present: the
   m-EventReport Confirmed Result PDU, the m-Get Result PDU, the m-Set
   Result PDU, the m-Action Confirmed Result PDU, the m-Create Result
   PDU, the m-Delete Result PDU, the GetListError Error PDU, and the
   SetListError Error PDU.

   All CMIP time fields shall use the ASN.1 GeneralizedTime type defined
   in [5] with 1 millisecond granularity.

   If the system generating the PDU does not have the current time, yet
   does have the time since last boot, then GeneralizedTime can be used
   to encode this information.  The time since last boot will be added
   to the base time "0001 Jan 1 00:00:00.00" using the Gregorian
   calendar algorithm.  (In the Gregorian calendar, all years have 365
   days except those divisible by 4 and not by 400, which have 366.) The
   use of the year 1 as the base year will prevent any confusion with
   current time.

   If no meaningful time is available, then the year 0 shall be used in
   GeneralizedTime to indicate this fact.

7.3.12.  Response PDUs

   Both the "managedObjectClass" and "managedObjectInstance" fields must
   be present in the following CMIP response PDUs: the m-EventReport
   Confirmed Result PDU, the m-Get Result PDU, the m-Set Result PDU, the
   m-Action Confirmed Result PDU, the m-Create Result PDU, the m-Delete
   Result PDU, the GetListError Error PDU, and the SetListError Error
   PDU.  The "managedObjectInstance" field must be present in the
   ProcessingFailure Error PDU.  The "managedObjectClass" field must be
   present in the NoSuchArgument Error PDU.

7.3.13.  Error PDUs

   The "globalId" form of AttributeId is required for the
   NoSuchAttributeId Error PDU and the InvalidAttributeValue Error PDU.

8.  Association Control Service Element

   The Association Control Service Element (ACSE), which is necessary



Warrier & Besaw                                                [Page 43]

RFC 1095                          CMOT                        April 1989


   for establishing and releasing application associations, is defined
   in [7] and [8].

8.1.  ACSE Services

   The ACSE service description is detailed in ISO 8649 [7].  All of the
   defined ACSE services are mandatory:

       o  A-ASSOCIATE: This confirmed service is used to initiate an
          application association between application entities.

       o  A-RELEASE: This confirmed service is used to release an
          application association between application entities without
          loss of information.

       o  A-ABORT: This unconfirmed service causes the abnormal release
          of an association with a possible loss of information.

       o  A-P-ABORT: This provider-initiated service indicates the
          abnormal release of an application association by the
          underlying presentation service with a possible loss of
          information.

   Mappings of the ACSE services to presentation services and ACSE APDUs
   are shown in Table 6, along with a section reference to ISO 8649 [7].


      +-------------+------------+----------------------+-------------+
      |    ACSE     |  ISO 8649  |        Related       |  Associated |
      |   Service   |  Reference | Presentation Service |    APDUs    |
      +-------------+------------+----------------------+-------------+
      | A-ASSOCIATE |     9.1    |       P-CONNECT      | AARQ, AARE  |
      | A-RELEASE   |     9.2    |       P-RELEASE      | RLRQ, RLRE  |
      | A-ABORT     |     9.3    |       P-U-ABORT      | ABRT        |
      | A-P-ABORT   |     9.4    |       P-P-ABORT      | (none)      |
      +-------------+------------+----------------------+-------------+

                     Table 6.  Mapping of ACSE Services


8.2.  Supporting Services

   ACSE will make use of the following ISO presentation layer services:
   P-CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT.  These presentation
   services will be provided by the LPP [13].






Warrier & Besaw                                                [Page 44]

RFC 1095                          CMOT                        April 1989


8.3.  ACSE Protocol

   The ACSE protocol specification is found in ISO 8650 [8]. All five
   ACSE APDUs specified in the standard are mandatory.

8.3.1.  Application Context Name

   The Application Context Name takes the form of an OBJECT IDENTIFIER.
   The value of this OBJECT IDENTIFIER includes both the version of CMOT
   being used for this association and the version number of the highest
   version of the Internet-standard MIB supported by the manager or
    agent.  The application context name has the following generic form:


                 { iso(1) org(3) dod(6) internet(1) mgmt(2) mib(n)
                   cmot(9) cmotVersion(1) version-number(v) }

                 where n = highest MIB version supported and
                       v = version of CMOT supported


   For the version of CMOT defined in these agreements, "version-number"
   has the value of one (1). This version of CMOT implies the versions
   of the ISO protocols specified in this memo (see Figure 2).

8.3.2.  User Information

   The following CMIS M-INITIALISE parameters are all mapped onto the
   ACSE User Information parameter: Functional Units, User Information,
   and Access Control.  (See section 7.1.4 for more information on the
   CMIS M-INITIALISE parameters.) ACSE User Information is defined in
   ISO 8650 as follows:

              Association-information ::= SEQUENCE OF EXTERNAL

   The ASN.1 defined type EXTERNAL, which is defined in section 35 of
   ISO 8824 [5], requires both an OBJECT IDENTIFIER for identification
   and an associated ASN.1 encoding.

   The OBJECT IDENTIFIER and syntax associated with the ACSE Functional
   Units EXTERNAL definition are found in [12]. The OBJECT IDENTIFIER is
   defined as { iso(1) standard(0) ips-osi-mips(9596) cmip(2) version(1)
   acse(0) functional-units(0) } and the syntax is a BIT STRING.

   The EXTERNAL definition for User Information is left unspecified at
   this time; it will be defined in a future memo.

   If some form of access control is required, a simple unencrypted



Warrier & Besaw                                                [Page 45]

RFC 1095                          CMOT                        April 1989


   password can be used.  The EXTERNAL for this simple access control
   will use the OBJECT IDENTIFIER { cmotAcseAccessControl } (Appendix A)
   and the syntax OCTET STRING. A more sophisticated authentication
   mechanism will be defined with another EXTERNAL definition in a
   future memo.

8.3.3.  Presentation Service Parameters

   The values and defaults of parameters to the ACSE primitives that are
   given to the presentation service are specified in RFC 1085 [13].

   For the Presentation Context Definition List parameter to the P-
   CONNECT service [13, p. 10], the value of the Abstract Syntax Name
   associated with the Presentation Context Identifier of value one (1)
   shall be identical to the OBJECT IDENTIFIER used for the Application
   Context Name (section 8.3.1).

   The Quality of Service parameter shall have the value of either
   "tcp-based" or "udp-based."

9.  Remote Operations Service Element

   The Remote Operations Service Element (ROSE), which provides the
   ability to invoke remote operations, is specified in ISO 9072-1 [9]
   and 9072-2 [10].  ROSE can only be used once an association has been
   established between two application entities.  ROSE is used to
   support CMISE; it is not intended to be used directly by management
   application processes.

9.1.   ROSE Services

   The ROSE service definition is detailed in ISO 9072-1 [9].  All of
   the defined ROSE services are mandatory:

       o  RO-INVOKE: This unconfirmed service is used by an invoking
          ROSE-user to cause the invocation of an operation to be
          performed by an invoked ROSE-user.

       o  RO-RESULT: This unconfirmed service is used by an invoked
          ROSE-user to reply to a previous RO-INVOKE indication in the
          case of a successfully performed operation.

       o  RO-ERROR: This unconfirmed service is used by an invoked
          ROSE-user to reply to a previous RO-INVOKE indication in the
          case of an unsuccessfully performed operation.

       o  RO-REJECT-U: This unconfirmed service is used by a ROSE-user
          to reject a request (RO-INVOKE indication) of the other



Warrier & Besaw                                                [Page 46]

RFC 1095                          CMOT                        April 1989


          ROSE-user if it has detected a problem.  It may also be used
          by a ROSE-user to (optionally) reject a reply (RO-RESULT
          indication, RO-ERROR indication) from the other ROSE-user.

       o  RO-REJECT-P: This provider-initiated service is used to advise
          a ROSE-user of a problem detected by the ROSE-provider.

   Mappings of ROSE services to ISO presentation services and ROSE APDUs
   are shown in Table 7, along with a section reference to ISO 9072-1
   [9].


      +-------------+------------+----------------------+-------------+
      |    ROSE     | ISO 9072-1 |        Related       |  Associated |
      |   Service   | Reference  | Presentation Service |    APDUs    |
      +-------------+------------+----------------------+-------------+
      | RO-INVOKE   |    10.1    |        P-DATA        |    ROIV     |
      | RO-RESULT   |    10.2    |        P-DATA        |    RORS     |
      | RO-ERROR    |    10.3    |        P-DATA        |    ROER     |
      | RO-REJECT-U |    10.4    |        P-DATA        |    RORJ     |
      | RO-REJECT-P |    10.5    |        P-DATA        |    RORJ     |
      +-------------+------------+----------------------+-------------+


   Table 7.  Mapping of ROSE Services


9.2.  Supporting Services

   ROSE will only make use of the presentation layer service P-DATA.
   This service is provided by the LPP.  The following restrictions are
   a consequence of the use of the LPP: First, mappings to the Reliable
   Transfer Service Element (RTSE) are not possible, since no RTSE is
   present.  Second, no data token is used with the presentation
   services.

9.3.  ROSE Protocol

   The protocol specification for ROSE shall follow ISO 9072-2 [10].
   All four APDUs specified in the standard are mandatory.  In addition,
   the ability to support the correct origination and reception of the
   linked-id protocol element is required if the multiple reply
   functional unit has been selected (section 7.1.2).

9.3.1.  Operation Class

   Since no turn management is required by ROSE, the Operation Class
   parameter may be ignored.



Warrier & Besaw                                                [Page 47]

RFC 1095                          CMOT                        April 1989


9.3.2.  Priority

   ROSE will deliver each APDU in a "first in, first out" manner.  Since
   no turn management is required by ROSE, the Priority parameter may be
   ignored.

10.  Lightweight Presentation

   The specification for the lightweight presentation protocol (LPP) is
   contained in RFC 1085, "ISO Presentation Services on top of TCP/IP-
   based internets" [13].  The services defined in that memo are the
   minimal set of ISO presentation services required to support ACSE and
   ROSE.  The protocol specified to provide these services is a
   replacement for the ISO presentation protocol.

10.1.  Lightweight Presentation Services

   All of the ISO presentation services provided by the LPP are
   mandatory: P-CONNECT, P-RELEASE, P-U-ABORT, P-P-ABORT, and P-DATA.

10.2.  Supporting Services

   Depending on the quality of service indicated in the P-CONNECT
   request, the LPP will use either UDP (low quality) or TCP (high
   quality) as the underlying transport protocol.  UDP provides an
   unreliable datagram service, while TCP provides a reliable
   connection-oriented transport service.

   Practically speaking, there are two ways to discover whether a remote
   system supports the LPP over UDP or TCP.  The first is to use some
   undefined form of directory service. This might be nothing more than
   a local table.  The second way is simply to attempt to establish an
   association with the remote application entity using the desired
   quality of service.  If the transport for that service is unavailable
   on the remote system, then the local presentation-service-provided
   will issue a negative P-CONNECT.CONFIRMATION primitive.  This will be
   interpreted by ACSE as a failure to establish an association with the
   desired quality of service.

   The following well-known UDP and TCP port numbers are defined:

             cmot manager     163/tcp
             cmot manager     163/udp
             cmot agent       164/tcp
             cmot agent       164/udp

   When UDP is used, an implementation need not accept a lightweight
   presentation PDU whose length exceeds 484.  The purpose of this



Warrier & Besaw                                                [Page 48]

RFC 1095                          CMOT                        April 1989


   restriction is to ensure that CMIP requests and responses can be
   transmitted in a single unfragmented IP datagram.

10.3.  Lightweight Presentation Protocol

   No further agreements are needed for the lightweight presentation
   protocol defined in RFC 1085.

11.  Acknowledgements

   This RFC is the work of many people.  The following members of the
   IETF Netman working group and other interested individuals made
   important contributions:

             Amatzia Ben-Artzi, 3Com
             Asheem Chandna, AT&T Bell Laboratories
             Ken Chapman, Digital Equipment Corporation
             Anthony Chung, Sytek
             George Cohn, Ungermann-Bass
             Gabriele Cressman, Sun Microsystems
             Pranati Kapadia, Hewlett-Packard
             Lee LaBarre, The MITRE Corporation (chair)
             Dave Mackie, 3Com
             Keith McCloghrie, The Wollongong Group
             Jim Robertson, 3Com
             Milt Roselinsky, CMC
             Marshall Rose, The Wollongong Group
             John Scott, Data General
             Lou Steinberg, IBM

12.  References

     [1]  Cerf, V., "IAB Recommendations for the Development of Internet
          Network Management Standards", RFC 1052, April 1988.

     [2]  Rose, M., and K. McCloghrie, "Structure and Identification of
          Management Information for TCP/IP-based internets", RFC 1065,
          August 1988.

     [3]  McCloghrie, K., and M. Rose, "Management Information Base for
          Network Management of TCP/IP-based internets", RFC 1066,
          August 1988.

     [4]  Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple
          Network Management Protocol (SNMP)", RFC 1098, (Obsoletes
          RFC 1067), April 1989.

     [5]  ISO 8824: "Information processing systems - Open Systems



Warrier & Besaw                                                [Page 49]

RFC 1095                          CMOT                        April 1989


          Interconnection, Specification of Abstract Syntax Notation One
          (ASN.1)", Geneva, March 1988.

     [6]  ISO 8825: "Information processing systems - Open Systems
          Interconnection, Specification of Basic Encoding Rules for
          Abstract Notation One (ASN.1)", Geneva, March 1988.

     [7]  ISO 8649: "Information processing systems - Open Systems
          Interconnection, Service Definition for Association Control
          Service Element".

     [8]  ISO 8650: "Information processing systems - Open Systems
          Interconnection, Protocol Specification for Association
          Control Service Element".

     [9]  CCITT Recommendation X.219, Working Document for ISO 9072-1:
          "Information processing systems - Text Communication, Remote
          Operations: Model, Notation and Service Definition",
          Gloucester, November 1987.

     [10]  CCITT Recommendation X.229, Working Document for ISO 9072-2:
           "Information processing systems - Text Communication, Remote
           Operations: Protocol Specification", Gloucester,
           November 1987.

     [11]  ISO DIS 9595-2: "Information processing systems - Open
           Systems Interconnection, Management Information Service
           Definition - Part 2: Common Management Information
           Service", 22 December 1988.

     [12]  ISO DIS 9596-2: "Information Processing Systems - Open
           Systems Interconnection, Management Information Protocol
           Specification - Part 2: Common Management Information
           Protocol", 22 December 1988.

     [13]  Rose, M., "ISO Presentation Services on top of TCP/IP-based
           internets", RFC 1085, December 1988.

     [14]  OSI Network Management Forum, "Forum Interoperable Interface
           Protocols", September 1988.

     [15]  ISO DIS 7498-4: "Information processing systems - Open
           Systems Interconnection, Basic Reference Model - Part 4:
           OSI Management Framework".

     [16]  ISO/IEC JTC1/SC21/WG4 N571: "Information processing systems -
           Open Systems Interconnection, Systems Management: Overview",
           London, July 1988.



Warrier & Besaw                                                [Page 50]

RFC 1095                          CMOT                        April 1989


     [17]  Klerer, S. Mark, "The OSI Management Architecture: An
           Overview", IEEE Network Magazine, March 1988.

     [18]  Ben-Artzi, A., "Network Management for TCP/IP Networks: An
           Overview", Internet Engineering Task Force working note,
           April 1988.

     [19]  ISO/IEC JTC1/SC21/WG4 N3324: "Information processing
           systems - Open Systems Interconnection, Management
           Information Services - Structure of Management
           Information - Part I: Management Information Model",
           Sydney, December 1988.

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

     [21]  Postel, J., "Transmission Control Protocol", RFC 793,
           September 1981.

     [22]  ISO DP 9534: "Information processing systems - Open Systems
           Interconnection, Application Layer Structure", 10 March 1987.

     [23]  Rose, M., "ISO Transport Services on top of the TCP",
           RFC 1006, May 1987.

     [24]  ISO 8822: "Information processing systems - Open Systems
           Interconnection, Connection Oriented Presentation Service
           Definition", June 1987.

     [25]  Postel, J., "Internet Protocol", RFC 791, September 1981.

     [26]  CCITT Draft Recommendation X.500, ISO DIS 9594/1-8: "The
           Directory", Geneva, March 1988.



















Warrier & Besaw                                                [Page 51]

RFC 1095                          CMOT                        April 1989


Appendix A - The CMOT Group

   CMOT DEFINITIONS ::= BEGIN

   IMPORTS OBJECT-TYPE FROM RFC1065-SMI;

   IMPORTS mib FROM RFC1066-MIB;

     cmot  OBJECT IDENTIFIER ::= { mib 9 }

     -- The following assignments are made for the purpose of
     -- identification within CMOT and do not refer to MIB objects.

     cmotVersion              OBJECT IDENTIFIER ::= { cmot 1 }

     cmotAcseInfo             OBJECT IDENTIFIER ::= { cmot 2 }
     cmotAcseAccessControl    OBJECT IDENTIFIER ::= { cmotAcseInfo 1 }

     -- The following definition is made for use in referencing a
     -- managed system (for the purpose of proxy management) in the
     -- CMIP Object Instance field. It does not represent a MIB
     -- object.

     cmotSystemID OBJECT-TYPE
             SYNTAX  CmotSystemID
             ACCESS  not-accessible
             STATUS  optional
             ::= { cmot 3 }

     CmotSystemID ::= CHOICE {
             arbitrary     [0] IMPLICIT OCTET STRING,
             proxyIndex    [1] IMPLICIT INTEGER,
             inetAddr      [2] IMPLICIT IpAddress,
             domainName    [3] IMPLICIT OCTET STRING,
             mac802Addr    [4] IMPLICIT OCTET STRING,
             x121Addr      [5] IMPLICIT OCTET STRING,
             nsap          [6] IMPLICIT OCTET STRING,
             netbiosName   [7] IMPLICIT OCTET STRING,
             snaName       [8] IMPLICIT OCTET STRING,
             adminId       [9] IMPLICIT OBJECT IDENTIFIER
     }

      -- All addresses should be conveyed in network-byte order.

   END






Warrier & Besaw                                                [Page 52]

RFC 1095                          CMOT                        April 1989


Appendix B - Management Information Summary

   RFC1066-MIB-INTERPRETATION

          { iso org(3) dod(6) internet(1) mgmt(2) 1 }

              DEFINITIONS ::= BEGIN

              IMPORTS mgmt, OBJECT-TYPE FROM RFC1065-SMI;

                mib        OBJECT IDENTIFIER ::= { mgmt 1 }

                system     OBJECT IDENTIFIER ::= { mib 1 }
                interfaces OBJECT IDENTIFIER ::= { mib 2 }
                at         OBJECT IDENTIFIER ::= { mib 3 }
                ip         OBJECT IDENTIFIER ::= { mib 4 }
                icmp       OBJECT IDENTIFIER ::= { mib 5 }
                tcp        OBJECT IDENTIFIER ::= { mib 6 }
                udp        OBJECT IDENTIFIER ::= { mib 7 }
                egp        OBJECT IDENTIFIER ::= { mib 8 }


         -- definition of object class

         OBJECT-CLASS MACRO  ::=
         BEGIN
           TYPE NOTATION  ::= SubClassOf Superiors Names Attributes
           VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)

           SubClassOf     ::= "SUBCLASS OF" value(OBJECT-CLASS)
                                            | empty
           Superiors      ::= "SUPERIORS" "{" SuperiorList "}"
                                            | empty
           Names          ::= "NAMES" "{" AttributeList "}"
                                            | empty
           Attributes     ::= "CONTAINS" "{" AttributeList "}"
                                            | empty

           SuperiorList   ::= Superior | Superior "," SuperiorList
           Superior       ::= value(OBJECT-CLASS)

           AttributeList  ::= Attribute | Attribute "," AttributeList
           Attribute      ::= value(OBJECT-TYPE)

         END

         -- the System group




Warrier & Besaw                                                [Page 53]

RFC 1095                          CMOT                        April 1989


         system OBJECT-CLASS
                 NAMES  { cmotSystemID }   -- Appendix A
                 CONTAINS  {
                         sysDescr,
                         sysObjectID,
                         sysUpTime
                 }
                 ::= { mib 1 }

         -- the Interfaces group

         interfaces OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  { ifNumber }
                 ::= { mib 2 }

         ifTable OBJECT-CLASS
                 SUPERIORS  { interfaces }
                 ::= { interfaces 2 }

         ifEntry OBJECT-CLASS
                 SUPERIORS  { ifTable }
                 NAMES { ifIndex }
                 CONTAINS  {
                         ifIndex,
                         ifDescr,
                         ifType,
                         ifMtu,
                         ifSpeed,
                         ifPhysAddress,
                         ifAdminStatus,
                         ifOperStatus,
                         ifLastChange,
                         ifInOctets,
                         ifInUcastPkts,
                         ifInNUcastPkts,
                         ifInDiscards,
                         ifInErrors,
                         ifInUnknownProtos,
                         ifOutOctets,
                         ifOutUcastPkts,
                         ifOutNUcastPkts,
                         ifOutDiscards,
                         ifOutErrors,
                         ifOutQLen
                 }
                 ::= { ifTable 1 }




Warrier & Besaw                                                [Page 54]

RFC 1095                          CMOT                        April 1989


         -- the Address Translation group

         at OBJECT-CLASS
                 SUPERIORS  { system }
                 ::= { mib 3 }

         atTable OBJECT-CLASS
                 SUPERIORS  { at }
                 ::= { at 1 }

         atEntry OBJECT-CLASS
                 SUPERIORS  { atTable }
                 NAMES  {
                         atIfIndex,
                         atNetAddress
                 }
                 CONTAINS  {
                         atIfIndex,
                         atPhysAddress,
                         atNetAddress
                 }
                 ::= { atTable 1 }

         -- the IP group

         ip OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  {
                         ipForwarding,
                         ipDefaultTTL,
                         ipInReceives,
                         ipInHdrErrors,
                         ipInAddrErrors,
                         ipForwDatagrams,
                         ipInUnknownProtos,
                         ipInDiscards,
                         ipInDelivers,
                         ipOutRequests,
                         ipOutDiscards,
                         ipOutNoRoutes,
                         ipReasmTimeout,
                         ipReasmReqds,
                         ipReasmOKs,
                         ipReasmFails,
                         ipFragOKs,
                         ipFragFails,
                         ipFragCreates
                 }



Warrier & Besaw                                                [Page 55]

RFC 1095                          CMOT                        April 1989


                 ::= { mib 4 }

         -- the IP Interface table

         ipAddrTable OBJECT-CLASS
                 SUPERIORS  { ip }
                 ::= { ip 20 }

         ipAddrEntry OBJECT-CLASS
                 SUPERIORS  { ipAddrTable }
                 NAMES  { ipAdEntAddr }
                 CONTAINS  {
                         ipAdEntAddr,
                         ipAdEntIfIndex,
                         ipAdEntNetMask,
                         ipAdEntBcastAddr
                 }
                 ::= { ipAddrTable 1 }

         -- the IP Routing table

         ipRoutingTable OBJECT-CLASS
                 SUPERIORS  { ip }
                 ::= { ip 21 }

         ipRouteEntry OBJECT-CLASS
                 SUPERIORS  { ipRoutingTable }
                 NAMES  { ipRouteDest }
                 CONTAINS  {
                         ipRouteDest,
                         ipRouteIfIndex,
                         ipRouteMetric1,
                         ipRouteMetric2,
                         ipRouteMetric3,
                         ipRouteMetric4,
                         ipRouteNextHop,
                         ipRouteType,
                         ipRouteProto,
                         ipRouteAge
                 }
                 ::= { ipRoutingTable 1 }

         -- the ICMP group

         icmp OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  {
                         icmpInMsgs,



Warrier & Besaw                                                [Page 56]

RFC 1095                          CMOT                        April 1989


                         icmpInErrors,
                         icmpInDestUnreachs,
                         icmpInTimeExcds,
                         icmpInParmProbs,
                         icmpInSrcQuenchs,
                         icmpInRedirects,
                         icmpInEchos,
                         icmpInEchoReps,
                         icmpInTimestamps,
                         icmpInTimestampReps,
                         icmpInAddrMasks,
                         icmpInAddrMaskReps,
                         icmpOutMsgs,
                         icmpOutErrors,
                         icmpOutDestUnreachs,
                         icmpOutTimeExcds,
                         icmpOutParmProbs,
                         icmpOutSrcQuenchs,
                         icmpOutRedirects,
                         icmpOutEchos,
                         icmpOutEchoReps,
                         icmpOutTimestamps,
                         icmpOutTimestampReps,
                         icmpOutAddrMasks,
                         icmpOutAddrMaskReps
                 }
                 ::= { mib 5 }

         -- the TCP group

         tcp OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  {
                         tcpRtoAlgorithm,
                         tcpRtoMin,
                         tcpRtoMax,
                         tcpMaxConn,
                         tcpActiveOpens,
                         tcpPassiveOpens,
                         tcpAttemptFails,
                         tcpEstabResets,
                         tcpCurrEstab,
                         tcpInSegs,
                         tcpOutSegs,
                         tcpRetransSegs
                 }
                 ::= { mib 6 }




Warrier & Besaw                                                [Page 57]

RFC 1095                          CMOT                        April 1989


         -- the TCP connections table

         tcpConnTable OBJECT-CLASS
                 SUPERIORS  { tcp }
                 ::= { tcp 13 }

         tcpConnEntry OBJECT-CLASS
                 SUPERIORS  { tcpConnTable }
                 NAMES  {
                         tcpConnLocalAddress,
                         tcpConnLocalPort,
                         tcpConnRemAddress,
                         tcpConnRemPort
                 }
                 CONTAINS  {
                         tcpConnState,
                         tcpConnLocalAddress,
                         tcpConnLocalPort,
                         tcpConnRemAddress,
                         tcpConnRemPort
                 }
                 ::= { tcpConnTable 1 }

         -- the UDP group

        udp OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  {
                         udpInDatagrams,
                         udpNoPorts,
                         udpInErrors,
                         udpOutDatagrams
                 }
                 ::= { mib 7 }


         -- the EGP group

          egp OBJECT-CLASS
                 SUPERIORS  { system }
                 CONTAINS  {
                         egpInMsgs,
                         egpInErrors,
                         egpOutMsgs,
                         egpOutErrors
                 }
                 ::= { mib 8 }




Warrier & Besaw                                                [Page 58]

RFC 1095                          CMOT                        April 1989


          -- the EGP Neighbor table

          egpNeighTable OBJECT-CLASS
                 SUPERIORS  { egp }
                 ::= { egp 5 }

         egpNeighEntry OBJECT-CLASS
                 SUPERIORS  { egpNeighTable }
                 NAMES  { egpNeighAddr }
                 CONTAINS  {
                         egpNeighState,
                         egpNeighAddr
                 }
                 ::= { egpNeighTable 1 }


         END


































Warrier & Besaw                                                [Page 59]

RFC 1095                          CMOT                        April 1989


Appendix C - Sample Protocol Exchanges

   The following are sample protocol exchanges between a manager and an
   agent.  The manager establishes an association with the agent,
   requests the number of IP address and header errors, requests the
   type of route corresponding to the destination address 10.0.0.51,
   requests the TCP connection with the well-known port for FTP, and
   then releases the association.  All of these samples show the
   lightweight presentation protocol being used over TCP.

   --
   -- the manager sends an ACSE association request carried in a
   -- presentation connect request PDU
   --

   {
      connectRequest {                             -- LPP
         version version-1,
         reference {
            callingSSUserReference "sri-nic.arpa",
            commonReference "880821222531Z"
         },
         asn 1.3.6.1.2.1.9.1.1,
         user-data {                               -- ACSE
            protocol-version version1,
            application-context-name 1.3.6.1.2.1.9.1.1,
            user-information {
               functionalUnits {
                  direct-reference 1.0.9596.2.1.0.0,
                  encoding {
                     single-ASN1-type '010110101010101010110B'
                                                         -- Full Manager
                  }
               }
            }
         }
      }
   }


   --
   -- the agent sends an ACSE association response carried in a
   -- presentation connect response PDU
   --

   {
      connectResponse {                           -- LPP
         user-data {



Warrier & Besaw                                                [Page 60]

RFC 1095                          CMOT                        April 1989


            user-information {                    -- ACSE
               functionalUnits {
                  direct-reference 1.0.9596.2.1.0.0,
                  encoding {
                     single-ASN1-type '101001010101010101110B'
                                                           -- Full Agent
                  }
               }
            }
         }
      }
   }


   --
   -- the manager sends a get request to read the values of
   -- ipInHdrErrors and ipInAddrErrors
   --

   {
      userData {                                   -- LPP
         ro-Invoke {                               -- ROSE
            invokeID 10,
            operation-value m-Get(3),
            argument {                             -- CMIP
               baseManagedObjectClass {
                  globalForm ip { 1.3.6.1.2.1.4 }
               },
               baseManagedObjectInstance {
                  distinguishedName {
                     relativeDistinguishedName {}
                  }
               },
               attributeIdList {
                  attributeId {
                     localID 4                     -- ipInHdrErrors
                  },
                  attributeId {
                     localID 5                     -- ipInAddrErrors
                  }
               }
            }
         }
      }
   }






Warrier & Besaw                                                [Page 61]

RFC 1095                          CMOT                        April 1989


   --
   -- the agent replies with a get response indicating that
   -- ipInHdrErrors = 0 and ipInAddrErrors = 2
   --

   {
      userData {                                   -- LPP
         ro-Result {                               -- ROSE
            invokeID 10,
            {
               operation-value m-Get(3),
               argument {                          -- CMIP
                  baseManagedObjectClass {
                     globalForm ip { 1.3.6.1.2.1.4 }
                  },
                  baseManagedObjectInstance {
                     distinguishedName {
                        relativeDistinguishedName {}
                     }
                  },
                  currentTime "19880821222541.300000Z",
                  attributeList {
                     attribute {
                        attributeId {
                           localID 4               -- ipInHdrErrors
                        },
                        attributeValue 0
                     },
                     attribute {
                        attributeId {
                           localID 5               -- ipInAddrErrors
                        },
                        attributeValue 2
                     }
                  }
               }
            }
         }
      }
   }


   --
   -- the manager sends a get request to discover the ipRouteType for
   -- the IP routing entry with ipRouteDest = 10.0.0.51
   --





Warrier & Besaw                                                [Page 62]

RFC 1095                          CMOT                        April 1989


   {
      userData {                                   -- LPP
         ro-Invoke {                               -- ROSE
            invokeID 11,
            operation-value m-Get (3),
            argument {                             -- CMIP
               baseManagedObjectClass {
                  globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
               },
               baseManagedObjectInstance {
                  distinguishedName {
                     relativeDistinguishedName {
                        attributeValueAssertion {
                           attributeType ipRouteDest
                                        { 1.3.6.1.2.1.4.21.1.1 },
                           attributeValue 10.0.0.51
                        }
                     }
                  }
               },
               attributeIdList {
                  attributeId {
                     localID 8                     -- ipRouteType
                  }
               }
            }
         }
      }
   }


   --
   -- the agent replies with a get response indicating the appropriate
   -- route type
   --

   {
      userData {                                   -- LPP
         ro-Result {                               -- ROSE
            invokeID 11,
            {
               operation-value m-Get(3),
               argument {                          -- CMIP
                  baseManagedObjectClass {
                     globalForm ipRouteEntry { 1.3.6.1.2.1.4.21.1 }
                  },
                  baseManagedObjectInstance {
                     distinguishedName {



Warrier & Besaw                                                [Page 63]

RFC 1095                          CMOT                        April 1989


                        relativeDistinguishedName {
                           attributeValueAssertion {
                              attributeType ipRouteDest
                                           { 1.3.6.1.2.1.4.21.1.1 },
                              attributeValue 10.0.0.51
                           }
                        }
                     }
                  },
                  currentTime "19880821222613.780000Z",
                  attributeList {
                     attribute {
                        attributeId {
                           localID 8               -- ipRouteType
                        },
                        attributeValue "direct"
                     }
                  }
               }
            }
         }
      }
   }


   --
   -- the manager sends a get request to read the TCP connection with
   -- the well-known port for FTP.
   --

   {
      userData {                                   -- LPP
         ro-Invoke {                               -- ROSE
            invokeID 12,
            operation-value m-Get(3),
            argument {                             -- CMIP
               baseManagedObjectClass {
                  globalForm tcpConnTable { 1.3.6.1.2.1.6.13 }
               },

               baseManagedObjectInstance {
                  distinguishedName {
                     relativeDistinguishedName { }
                  }
               },
               scope oneLevel(1),
               filter {
                  item {



Warrier & Besaw                                                [Page 64]

RFC 1095                          CMOT                        April 1989


                     equality {
                        attributeType tcpConnLocalPort
                              { 1.3.6.1.2.1.6.13.1.3 }
                        attributeValue 21           -- ftp
                     }
                  }
               }
               attributeIdList { } -- an empty list means all attributes
            }
         }
      }
   }


   --
   -- the agent replies with a get response providing the desired TCP
   -- connection information. If more than one TCP connection had
   -- satisfied the filter condition, a series of one or more linked
   -- reply PDUs would have been returned before the final get response.
   --

   {
      userData {                                   -- LPP
         ro-Result {                               -- ROSE
            invokeID 12,
            {
               operation-value m-Get(3),
               argument {                          -- CMIP
                  baseManagedObjectClass {
                     globalForm tcpConnEntry { 1.3.6.1.2.1.6.13.1 }
                  },
                  baseManagedObjectInstance {
                     distinguishedName {
                        relativeDistinguishedName {
                           attributeValueAssertion {
                              attributeType  { tcpConnLocalAddress },
                              attributeValue 128.10.0.34
                           },
                           attributeValueAssertion {
                              attributeType  { tcpConnLocalPort },
                              attributeValue 21
                           },
                           attributeValueAssertion {
                              attributeType  { tcpConnRemAddress },
                              attributeValue 0.0.0.0
                           },
                           attributeValueAssertion {
                              attributeType  { tcpConnRemPort },



Warrier & Besaw                                                [Page 65]

RFC 1095                          CMOT                        April 1989


                              attributeValue 0
                           },
                        }
                     }
                  },
                  currentTime "19880821222541.300000Z",
                  attributeList {
                     attribute {
                        attributeId {
                           localId 1              -- tcpConnState
                        },
                        attributeValue LISTEN
                     },
                     attribute {
                        attributeId {
                           localId 2              -- tcpConnLocalAddress
                        },
                        attributeValue 128.10.0.34
                     },
                     attribute {
                        attributeId {
                           localId 3              -- tcpConnLocalPort
                        },
                        attributeValue 21
                     },
                     attribute {
                        attributeId {
                           localId 4              -- tcpConnRemAddress
                        },
                        attributeValue 0.0.0.0
                     },
                     attribute {
                        attributeId {
                           localId 5              -- tcpConnRemPort
                        },
                        attributeValue 0
                     }
                  }
               }
            }
         }
      }
   }








Warrier & Besaw                                                [Page 66]

RFC 1095                          CMOT                        April 1989


   --
   -- the manager sends a presentation release request
   --

   {
      releaseRequest {                             -- LPP
         user-data {                               -- ACSE
            reason normal
         }
      }
   }


   --
   -- the agent sends a presentation release response
   --

   {
      releaseResponse {                            -- LPP
         user-data {                               -- ACSE
            reason normal
         }
      }
   }


Authors' Addresses

   Unnikrishnan S. Warrier
   Unisys Corporation
   2400 Colorado  MS #42-13
   Santa Monica, CA 90406

   Phone: (213) 453-5196

   Email: unni@cs.ucla.edu


   Larry Besaw
   Hewlett-Packard
   3404 East Harmony Road
   Fort Collins, CO 80525

   Phone: (303) 229-6022

   Email: lmb%hpcndaw@hplabs.hp.com





Warrier & Besaw                                                [Page 67]