1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1864 1865 1866 1867 1868 1869 1870 1871 1872 1873 1874 1875 1876 1877 1878 1879 1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2327 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354 2355 2356 2357 2358 2359 2360 2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405 2406 2407 2408 2409 2410 2411
|
Network Working Group A. Bierman
Request for Comments: 2074 Cisco Systems
Category: Standards Track R. Iddon
AXON Networks,Inc.
January 1997
Remote Network Monitoring MIB Protocol Identifiers
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Table of Contents
1 Introduction .................................................... 3
2 The SNMP Network Management Framework ........................... 3
2.1 Object Definitions ............................................ 3
3 Overview ........................................................ 3
3.1 Terms ......................................................... 4
3.2 Relationship to the Remote Network Monitoring MIB ............. 6
3.3 Relationship to the Other MIBs ................................ 6
4 Protocol Identifier Encoding .................................... 7
4.1 ProtocolDirTable INDEX Format Examples ........................ 9
4.2 Protocol Identifier Macro Format .............................. 10
4.2.1 Mapping of the Protocol Name ................................ 12
4.2.2 Mapping of the VARIANT-OF Clause ............................ 13
4.2.3 Mapping of the PARAMETERS Clause ............................ 13
4.2.3.1 Mapping of the 'countsFragments(0)' BIT ................... 14
4.2.3.2 Mapping of the 'tracksSessions(1)' BIT .................... 15
4.2.4 Mapping of the ATTRIBUTES Clause ............................ 15
4.2.5 Mapping of the DESCRIPTION Clause ........................... 15
4.2.6 Mapping of the CHILDREN Clause .............................. 16
4.2.7 Mapping of the ADDRESS-FORMAT Clause ........................ 16
4.2.8 Mapping of the DECODING Clause .............................. 16
4.2.9 Mapping of the REFERENCE Clause ............................. 17
4.2.10 Evaluating a Protocol-Identifier INDEX ..................... 17
5 Protocol Identifier Macros ...................................... 18
5.1 Base Identifier Encoding ...................................... 18
5.1.1 Protocol Identifier Functions ............................... 19
5.1.1.1 Function 0: No-op ......................................... 19
5.1.1.2 Function 1: Protocol Wildcard Function .................... 19
5.2 Base Layer Protocol Identifiers ............................... 20
5.2.1 Ether2 Encapsulation ........................................ 21
Bierman & Iddon Standards Track [Page 1]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.2 LLC Encapsulation ........................................... 22
5.2.3 SNAP over LLC (OUI=000) Encapsulation ....................... 23
5.2.4 SNAP over LLC (OUI != 000) Encapsulation .................... 24
5.2.5 IANA Assigned Protocols ..................................... 25
5.2.5.1 IANA Assigned Protocol Identifiers ........................ 27
5.3 L3: Children of Base Protocol Identifiers ..................... 27
5.3.1 IP .......................................................... 28
5.3.2 IPX ......................................................... 29
5.3.3 ARP ......................................................... 30
5.3.4 IDP ......................................................... 30
5.3.5 AppleTalk ARP ............................................... 31
5.3.6 AppleTalk ................................................... 31
5.4 L4: Children of L3 Protocols .................................. 32
5.4.1 ICMP ........................................................ 32
5.4.2 TCP ......................................................... 32
5.4.3 UDP ......................................................... 33
5.5 L5: Application Layer Protocols ............................... 33
5.5.1 FTP ......................................................... 33
5.5.1.1 FTP-DATA .................................................. 33
5.5.1.2 FTP Control ............................................... 34
5.5.2 Telnet ...................................................... 34
5.5.3 SMTP ........................................................ 34
5.5.4 DNS ......................................................... 35
5.5.5 BOOTP ....................................................... 35
5.5.5.1 Bootstrap Server Protocol ................................. 35
5.5.5.2 Bootstrap Client Protocol ................................. 35
5.5.6 TFTP ........................................................ 36
5.5.7 HTTP ........................................................ 36
5.5.8 POP3 ........................................................ 36
5.5.9 SUNRPC ...................................................... 37
5.5.10 NFS ........................................................ 38
5.5.11 SNMP ....................................................... 38
5.5.11.1 SNMP Request/Response .................................... 38
5.5.11.2 SNMP Trap ................................................ 39
6 Acknowledgements ................................................ 39
7 References ...................................................... 40
8 Security Considerations ......................................... 43
9 Authors' Addresses .............................................. 43
Bierman & Iddon Standards Track [Page 2]
RFC 2074 RMON Protocol Identifiers January 1997
1. Introduction
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community. In particular, it describes the algorithms
required to identify different protocol encapsulations managed with
the Remote Network Monitoring MIB Version 2 [RMON2]. Although related
to the original Remote Network Monitoring MIB [RFC1757], this
document refers only to objects found in the RMON-2 MIB.
2. The SNMP Network Management Framework
The SNMP Network Management Framework presently consists of three
major components. They are:
o the SMI, described in RFC 1902 [RFC1902], - the mechanisms used for
describing and naming objects for the purpose of management.
o the MIB-II, STD 17, RFC 1213 [RFC1213], - the core set of managed
objects for the Internet suite of protocols.
o the protocol, STD 15, RFC 1157 [RFC1157] and/or RFC 1905 [RFC1905],
- the protocol for accessing managed information.
Textual conventions are defined in RFC 1903 [RFC1903], and
conformance statements are defined in RFC 1904 [RFC1904].
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2.1. Object Definitions
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name. The object
type together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience, we
often use a textual string, termed the descriptor, to refer to the
object type.
3. Overview
The RMON-2 MIB [RMON2] uses hierarchically formatted OCTET STRINGs to
globally identify individual protocol encapsulations in the
protocolDirTable.
Bierman & Iddon Standards Track [Page 3]
RFC 2074 RMON Protocol Identifiers January 1997
This guide contains algorithms and examples of protocol identifier
encapsulations for use as INDEX values in the protocolDirTable.
This document is not intended to be an authoritative reference on the
protocols described herein. Refer to the Official Internet Standards
document [RFC1800], the Assigned Numbers document [RFC1700], or other
appropriate RFCs, IEEE documents, etc. for complete and authoritative
protocol information.
3.1. Terms
Several terms are used throughout this document, as well as in the
RMON-2 MIB [RMON2], that should be introduced:
layer-identifier:
An octet string fragment representing a particular protocol
encapsulation layer. A string fragment identifying a particular
protocol encapsulation layer. This string is exactly four octets,
(except for the 'vsnap' base-layer identifier, which is exactly
eight octets) encoded in network byte order. A particular protocol
encapsulation can be identified by starting with a base layer
encapsulation (see the 'Base Protocol Identifiers' section for more
detail), and following the encoding rules specified in the CHILDREN
clause and assignment section for that layer. Then repeat for each
identified layer in the encapsulation. (See section 4.2.10
'Evaluating a Protocol-Identifier INDEX' for more detail.)
protocol:
A particular protocol layer, as specified by encoding rules in this
document. Usually refers to a single layer in a given
encapsulation. Note that this term is sometimes used in the RMON-2
MIB [RMON2] to name a fully-specified protocol-identifier string.
In such a case, the protocol-identifier string is named for its
upper-most layer. A named protocol may also refer to any
encapsulation of that protocol.
protocol-identifier string:
An octet string representing a particular protocol encapsulation,
as specified by encoding rules in this document. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirID object. A
protocol-identifier string is composed of one or more layer-
identifiers.
Bierman & Iddon Standards Track [Page 4]
RFC 2074 RMON Protocol Identifiers January 1997
protocol-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. The macro serves several
purposes:
- Name the protocol for use within the RMON-2 MIB [RMON2].
- Describe how the protocol is encoded into an octet string.
- Describe how child protocols are identified (if applicable),
and encoded into an octet string.
- Describe which protocolDirParameters are allowed for the protocol.
- Describe how the associated protocolDirType object is encoded
for the protocol.
- Provide reference(s) to authoritative documentation for the
protocol.
protocol-variant-identifier macro:
A group of formatted text describing a particular protocol layer,
as used within the RMON-2 MIB [RMON2]. This protocol is a variant
of a well known encapsulation that may be present in the
protocolDirTable. This macro is used to document the IANA
assigned protocols, which are needed to identify protocols which
cannot be practically identified by examination of 'appropriate
network traffic' (e.g. the packets which carry them). All other
protocols (which can be identified by examination of appropriate
network traffic) should be documented using the protocol-identifier
macro. A protocol-variant-identifier is documented using the
protocol-variant version of the protocol-identifier macro.
protocol-parameter:
A single octet, corresponding to a specific layer-identifier in the
protocol-identifier. This octet is a bit-mask indicating special
functions or capabilities that this agent is providing for the
corresponding protocol.
protocol-parameters string:
An octet string, which contains one protocol-parameter for each
layer-identifier in the protocol-identifier. See the section
'Mapping of the PARAMETERS Clause' for more detail. This string is
identified in the RMON-2 MIB [RMON2] as the protocolDirParameters
object.
protocolDirTable INDEX:
A protocol-identifier and protocol-parameters octet string pair
that have been converted to an INDEX value, according to the
encoding rules in in section 7.7 of RFC 1902 [RFC1902].
Bierman & Iddon Standards Track [Page 5]
RFC 2074 RMON Protocol Identifiers January 1997
pseudo-protocol:
A convention or algorithm used only within this document for the
purpose of encoding protocol-identifier strings.
3.2. Relationship to the Remote Network Monitoring MIB
This document is intended to identify possible string values for the
OCTET STRING objects protocolDirID and protocolDirParameters. Tables
in the new Protocol Distribution, Host, and Matrix groups use a local
INTEGER INDEX, in order to remain unaffected by changes in this
document. Only the protocolDirTable uses the strings (protocolDirID
and protocolDirParameters) described in this document.
This document is not intended to limit the protocols that may be
identified for counting in the RMON-2 MIB. Many protocol
encapsulations, not explicitly identified in this document, may be
present in an actual implementation of the protocolDirTable. Also,
implementations of the protocolDirTable may not include all the
protocols identified in the example section below.
This document is intentionally separated from the MIB objects to
allow frequent updates to this document without any republication of
MIB objects. Protocol Identifier macros submitted from the RMON
working group and community at large (to the RMONMIB WG mailing list
at 'rmonmib@cisco.com') will be collected and added to this document.
Macros submissions will be collected in the IANA's MIB files under
the directory "ftp://ftp.isi.edu/mib/rmonmib/rmon2_pi_macros/" and in
the RMONMIB working group mailing list message archive file
"ftp://ftp.cisco.com/ftp/rmonmib/rmonmib".
This document does not discuss auto-discovery and auto-population of
the protocolDirTable. This functionality is not explicitly defined by
the RMON standard. An agent should populate the directory with
'interesting' protocols--depending on the intended applications.
3.3. Relationship to the Other MIBs
The RMON Protocol Identifiers document is intended for use with the
protocolDirTable within the RMON MIB. It is not relevant to any other
MIB, or intended for use with any other MIB.
Bierman & Iddon Standards Track [Page 6]
RFC 2074 RMON Protocol Identifiers January 1997
4. Protocol Identifier Encoding
The protocolDirTable is indexed by two OCTET STRINGs, protocolDirID
and protocolDirParameters. To encode the table index, each variable-
length string is converted to an OBJECT IDENTIFIER fragment,
according to the encoding rules in section 7.7 of RFC 1902 [RFC1902].
Then the index fragments are simply concatenated. (Refer to figures
1a - 1d below for more detail.)
The first OCTET STRING (protocolDirID) is composed of one or more 4-
octet "layer-identifiers". The entire string uniquely identifies a
particular protocol encapsulation tree. The second OCTET STRING,
(protocolDirParameters) which contains a corresponding number of 1-
octet protocol-specific parameters, one for each 4-octet layer-
identifier in the first string.
A protocol layer is normally identified by a single 32-bit value.
Each layer-identifier is encoded in the ProtocolDirID OCTET STRING
INDEX as four sub-components [ a.b.c.d ], where 'a' - 'd' represent
each byte of the 32-bit value in network byte order. If a particular
protocol layer cannot be encoded into 32 bits, (except for the
'vsnap' base layer) then it must be defined as a 'ianaAssigned'
protocol (see below for details on IANA assigned protocols).
The following figures show the differences between the OBJECT
IDENTIFIER and OCTET STRING encoding of the protocol identifier
string.
Fig. 1a
protocolDirTable INDEX Format
-----------------------------
+---+--------------------------+---+---------------+
| c ! | c ! protocolDir |
| n ! protocolDirID | n ! Parameters |
| t ! | t ! |
+---+--------------------------+---+---------------+
Bierman & Iddon Standards Track [Page 7]
RFC 2074 RMON Protocol Identifiers January 1997
Fig. 1b
protocolDirTable OCTET STRING Format
------------------------------------
protocolDirID
+----------------------------------------+
| |
| 4 * N octets |
| |
+----------------------------------------+
protocolDirParameters
+----------+
| |
| N octets |
| |
+----------+
Fig. 1c
protocolDirTable INDEX Format Example
-------------------------------------
protocolDirID protocolDirParameters
+---+--------+--------+--------+--------+---+---+---+---+---+
| c | proto | proto | proto | proto | c |par|par|par|par|
| n | base | L3 | L4 | L5 | n |ba-| L3| L4| L5|
| t |(+flags)| | | | t |se | | | |
+---+--------+--------+--------+--------+---+---+---+---+---+ subOID
| 1 | 4 or 8 | 4 | 4 | 4 | 1 |1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8 sub-identifiers,
All other protocol layers are either encoded into 4 sub-identifiers
or encoded as a 'ianaAssigned' protocol.
Bierman & Iddon Standards Track [Page 8]
RFC 2074 RMON Protocol Identifiers January 1997
Fig. 1d
protocolDirTable OCTET STRING Format Example
--------------------------------------------
protocolDirID
+--------+--------+--------+--------+
| proto | proto | proto | proto |
| base | L3 | L4 | L5 |
| | | | |
+--------+--------+--------+--------+ octet
| 4 or 8 | 4 | 4 | 4 | count
protocolDirParameters
+---+---+---+---+
|par|par|par|par|
|ba-| L3| L4| L5|
|se | | | |
+---+---+---+---+ octet
|1/2| 1 | 1 | 1 | count
where N is the number of protocol-layer-identifiers required
for the entire encapsulation of the named protocol. Note that
the 'vsnap' base layer identifier is encoded into 8
protocolDirID sub-identifiers and 2 protocolDirParameters
sub-identifiers.
Although this example indicates four encapsulated protocols, in
practice, any non-zero number of layer-identifiers may be present,
theoretically limited only by OBJECT IDENTIFIER length restrictions,
as specified in section 3.5 of RFC 1902 [RFC1902].
Note that these two strings would not be concatenated together if
ever returned in a GetResponse PDU, since they are different MIB
objects. However, protocolDirID and protocolDirParameters are not
currently readable MIB objects.
4.1. ProtocolDirTable INDEX Format Examples
-- HTTP; fragments counted from IP and above
ether2.ip.tcp.www-http =
16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.80.4.0.1.0.0
-- SNMP over UDP/IP over SNAP
snap.ip.udp.snmp =
16.0.0.0.3.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
Bierman & Iddon Standards Track [Page 9]
RFC 2074 RMON Protocol Identifiers January 1997
-- SNMP over IPX over SNAP
snap.ipx.snmp =
12.0.0.0.3.0.0.129.55.0.0.144.15.3.0.0.0
-- SNMP over IPX over raw8023
-- ianaAssigned(ipxOverRaw8023(1)).snmp =
12.0.0.0.5.0.0.0.1.0.0.155.15.3.0.0.0
-- IPX over LLC
llc.ipx =
8.0.0.0.2.0.224.224.3.2.0.0
-- SNMP over UDP/IP over any link layer
-- wildcard-ether2.ip.udp.snmp
16.1.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161.4.0.0.0.0
-- IP over any link layer; base encoding is IP over ether2
-- wildcard-ether2.ip
8.1.0.0.1.0.0.8.0.2.0.0
-- AppleTalk Phase 2 over ether2
-- ether2.atalk
8.0.0.0.1.0.0.128.155.2.0.0
-- AppleTalk Phase 2 over vsnap
-- vsnap(apple).atalk
12.0.0.0.4.0.8.0.7.0.0.128.155.3.0.0.0
4.2. Protocol Identifier Macro Format
The following example is meant to introduce the protocol-identifier
macro. (The syntax is not quite ASN.1.) This macro is used to
represent both protocols and protocol-variants.
If the 'VariantOfPart' component of the macro is present, then the
macro represents a protocol-variant instead of a protocol. A
protocol- variant-identifier is used only for IANA assigned
protocols, enumerated under the 'ianaAssigned' base-layer.
Bierman & Iddon Standards Track [Page 10]
RFC 2074 RMON Protocol Identifiers January 1997
RMON-PROTOCOL-IDENTIFIER MACRO ::=
BEGIN
PIMacroName "PROTOCOL-IDENTIFIER"
VariantOfPart
"PARAMETERS" ParamPart
"ATTRIBUTES" AttrPart
"DESCRIPTION" Text
ChildDescrPart
AddrDescrPart
DecodeDescrPart
ReferPart
"::=" "{" EncapsPart "}"
PIMacroName ::=
identifier
VariantOfPart ::=
"VARIANT-OF" identifier | empty
ParamPart ::=
"{" ParamList "}"
ParamList ::=
Params | empty
Params ::=
Param | Params "," Param
Param ::=
identifier "(" nonNegativeNumber ")"
AttrPart ::=
"{" AttrList "}"
AttrList ::=
Attrs | empty
Attrs ::=
Attr | Attrs "," Attr
Attr ::=
identifier "(" nonNegativeNumber ")"
ChildDescrPart ::=
"CHILDREN" Text | empty
AddrDescrPart ::=
"ADDRESS-FORMAT" Text | empty
Bierman & Iddon Standards Track [Page 11]
RFC 2074 RMON Protocol Identifiers January 1997
DecodeDescrPart ::=
"DECODING" Text | empty
ReferPart ::=
"REFERENCE" Text | empty
EncapsPart ::=
"{" Encaps "}"
Encaps ::=
Encap | Encaps "," Encap
Encap ::=
BaseEncap | NormalEncap | VsnapEncap | IanaEncap
BaseEncap ::=
nonNegativeNumber
NormalEncap ::=
identifier nonNegativeNumber
VsnapEncap ::=
identifier "(" nonNegativeNumber ")" nonNegativeNumber
IanaEncap ::=
"ianaAssigned" nonNegativeNumber
| "ianaAssigned" identifier
| "ianaAssigned" identifier "(" nonNegativeNumber ")"
Text ::=
"""" string """"
END
4.2.1. Mapping of the Protocol Name
The 'PIMacroName' value should be a lower-case ASCII string, and
contain the name or acronym identifying the protocol. NMS
applications may treat protocol names as case-insensitive strings,
and agent implementations must make sure the protocolDirTable does
not contain any instances of the protocolDirDescr object which differ
only in the case of one of more letters (if the identifiers are
intended to represent different protocols).
It is possible that different encapsulations of the same protocol
(which are represented by different entries in the protocolDirTable)
will be assigned the same protocol name.
Bierman & Iddon Standards Track [Page 12]
RFC 2074 RMON Protocol Identifiers January 1997
A protocol name should match the "most well-known" name or acronym
for the indicated protocol. For example, the document indicated by
the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
defines IP Protocol field values, so protocol-identifier macros for
children of IP should be given names consistent with the protocol
names found in this authoritative document.
4.2.2. Mapping of the VARIANT-OF Clause
This clause is present for IANA assigned protocols only. It
identifies the protocol-identifier macro that most closely represents
this particular protocol, and is known as the "reference protocol".
(A protocol-identifier macro must exist for the reference protocol.)
When this clause is present in a protocol-identifier macro, the macro
is called a 'protocol-variant-identifier'.
Any clause (e.g. CHILDREN, ADDRESS-FORMAT) in the reference protocol-
identifier macro should not be duplicated in the protocol-variant-
identifier macro, if the 'variant' protocols' semantics are identical
for a given clause.
Since the PARAMETERS and ATTRIBUTES clauses must be present in a
protocol-identifier, an empty 'ParamPart' and 'AttrPart' (i.e.
"PARAMETERS {}") must be present in a protocol-variant-identifier
macro, and the 'ParamPart' and 'AttrPart' found in the reference
protocol- identifier macro examined instead.
Note that if a 'ianaAssigned' protocol is defined that is not a
variant of any other documented protocol, then the protocol-
identifier macro should be used instead of the protocol-variant-
identifier version of the macro.
4.2.3. Mapping of the PARAMETERS Clause
The protocolDirParameters object provides an NMS the ability to turn
on and off expensive probe resources. An agent may support a given
parameter all the time, not at all, or subject to current resource
load.
The PARAMETERS clause is a list of bit definitions which can be
directly encoded into the associated ProtocolDirParameters octet in
network byte order. Zero or more bit definitions may be present. Only
bits 0-7 are valid encoding values. This clause defines the entire
BIT set allowed for a given protocol. A conforming agent may choose
to implement a subset of zero or more of these PARAMETERS.
Bierman & Iddon Standards Track [Page 13]
RFC 2074 RMON Protocol Identifiers January 1997
By convention, the following common bit definitions are used by
different protocols. These bit positions must not be used for other
parameters. They should be reserved if not used by a given protocol.
Bits are encoded in network-byte order.
Table 3.1 Reserved PARAMETERS Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 countsFragments higher-layer protocols encapsulated within
this protocol will be counted correctly even
if this protocol fragments the upper layers
into multiple packets.
1 tracksSessions correctly attributes all packets of a protocol
which starts sessions on well known ports or
sockets and then transfers them to dynamically
assigned ports or sockets thereafter (e.g. TFTP).
The PARAMETERS clause must be present in all protocol-identifier
macro declarations, but may be equal to zero (empty). Note that an
NMS must determine if a given PARAMETER bit is supported by
attempting to create the desired protocolDirEntry The associated
ATTRIBUTE bits for 'countsFragments' and 'tracksSessions' do not
exist.
4.2.3.1. Mapping of the 'countsFragments(0)' BIT
This bit indicates whether the probe is correctly attributing all
fragmented packets of the specified protocol, even if individual
frames carrying this protocol cannot be identified as such. Note
that the probe is not required to actually present any re-assembled
datagrams (for address-analysis, filtering, or any other purpose) to
the NMS.
This bit may only be set in a protocolDirParameters octet which
corresponds to a protocol that supports fragmentation and reassembly
in some form. Note that TCP packets are not considered 'fragmented-
streams' and so TCP is not eligible.
This bit may be set in at most one protocolDirParameters octet within
a protocolDirTable INDEX.
Bierman & Iddon Standards Track [Page 14]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.3.2. Mapping of the 'tracksSessions(1)' BIT
The 'tracksSessions(1)' bit indicates whether frames which are part
of remapped-sessions (e.g. TFTP download sessions) are correctly
counted by the probe. For such a protocol, the probe must usually
analyze all packets received on the indicated interface, and maintain
some state information, (e.g. the remapped UDP port number for TFTP).
The semantics of the 'tracksSessions' parameter are independent of
the other protocolDirParameters definitions, so this parameter may be
combined with any other legal parameter configurations.
4.2.4. Mapping of the ATTRIBUTES Clause
The protocolDirType object provides an NMS with an indication of a
probe's capabilities for decoding a given protocol, or the general
attributes of the particular protocol.
The ATTRIBUTES clause is a list of bit definitions which are encoded
into the associated instance of ProtocolDirType. The BIT definitions
are specified in the SYNTAX clause of the protocolDirType MIB object.
Table 3.2 Reserved ATTRIBUTES Bits
------------------------------------
Bit Name Description
---------------------------------------------------------------------
0 hasChildren indicates that there may be children of
this protocol defined in the protocolDirTable
(by either the agent or the manager).
1 addressRecognitionCapable
indicates that this protocol can be used
to generate host and matrix table entries.
The ATTRIBUTES clause must be present in all protocol-identifier
macro declarations, but may be empty.
4.2.5. Mapping of the DESCRIPTION Clause
The DESCRIPTION clause provides a textual description of the protocol
identified by this macro. Notice that it should not contain details
about items covered by the CHILDREN, ADDRESS-FORMAT, DECODING and
REFERENCE clauses.
The DESCRIPTION clause must be present in all protocol-identifier
macro declarations.
Bierman & Iddon Standards Track [Page 15]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.6. Mapping of the CHILDREN Clause
The CHILDREN clause provides a description of child protocols for
protocols which support them. It has three sub-sections:
- Details on the field(s)/value(s) used to select the child protocol,
and how that selection process is performed
- Details on how the value(s) are encoded in the protocol identifier
octet string
- Details on how child protocols are named with respect to their
parent protocol label(s)
The CHILDREN clause must be present in all protocol-identifier macro
declarations in which the 'hasChildren(0)' BIT is set in the
ATTRIBUTES clause.
4.2.7. Mapping of the ADDRESS-FORMAT Clause
The ADDRESS-FORMAT clause provides a description of the OCTET-STRING
format(s) used when encoding addresses.
This clause must be present in all protocol-identifier macro
declarations in which the 'addressRecognitionCapable(1)' BIT is set
in the ATTRIBUTES clause.
4.2.8. Mapping of the DECODING Clause
The DECODING clause provides a description of the decoding procedure
for the specified protocol. It contains useful decoding hints for the
implementor, but should not over-replicate information in documents
cited in the REFERENCE clause. It might contain a complete
description of any decoding information required.
For 'extensible' protocols ('hasChildren(0)' BIT set) this includes
offset and type information for the field(s) used for child selection
as well as information on determining the start of the child
protocol.
For 'addressRecognitionCapable' protocols this includes offset and
type information for the field(s) used to generate addresses.
The DECODING clause is optional, and may be omitted if the REFERENCE
clause contains pointers to decoding information for the specified
protocol.
Bierman & Iddon Standards Track [Page 16]
RFC 2074 RMON Protocol Identifiers January 1997
4.2.9. Mapping of the REFERENCE Clause
If a publicly available reference document exists for this protocol
it should be listed here. Typically this will be a URL if possible;
if not then it will be the name and address of the controlling body.
The CHILDREN, ADDRESS-FORMAT, and DECODING clauses should limit the
amount of information which may currently be obtained from an
'authoritative' document, such as the Assigned Numbers document
[RFC1700]. Any duplication or paraphrasing of information should be
brief and consistent with the authoritative document.
The REFERENCE clause is optional, but should be implemented if an
authoritative reference exists for the protocol (especially for
standard protocols).
4.2.10. Evaluating a Protocol-Identifier INDEX
The following evaluation is done after protocolDirTable INDEX value
has been converted into two OCTET STRINGs according to the INDEX
encoding rules specified in the SMI [RFC1902].
Protocol-identifiers are evaluated left to right, starting with the
protocolDirID, which length should be evenly divisible by four. The
protocolDirParameters length should be exactly one quarter of the
protocolDirID string length.
Protocol-identifier parsing starts with the base layer identifier,
which must be present, and continues for one or more upper layer
identifiers, until all OCTETs of the protocolDirID have been used.
Layers may not be skipped, so identifiers such as 'SNMP over IP' or
'TCP over anylink' can not exist.
The base-layer-identifier also contains a 'special function
identifier' which may apply to the rest of the protocol identifier.
Wild-carding at the base layer within a protocol encapsulation is the
only supported special function at this time. Refer to the 'Base
Protocol Identifiers' section for wildcard encoding rules.
After the protocol-tree identified in protocolDirID has been parsed,
each parameter bit-mask (one octet for each 4-octet layer-identifier)
is evaluated, and applied to the corresponding protocol layer.
A protocol-identifier label may map to more than one value. For
instance, 'ip' maps to 5 distinct values, one for each supported
encapsulation. (see the 'IP' section under 'L3 Protocol
Identifiers'),
Bierman & Iddon Standards Track [Page 17]
RFC 2074 RMON Protocol Identifiers January 1997
It is important to note that these macros are conceptually expanded
at implementation time, not at run time.
If all the macros are expanded completely by substituting all
possible values of each label for each child protocol, a list of all
possible protocol-identifiers is produced. So 'ip' would result in 5
distinct protocol-identifiers. Likewise each child of 'ip' would map
to at least 5 protocol-identifiers, one for each encapsulation (e.g.
ip over ether2, ip over LLC, etc.).
5. Protocol Identifier Macros
The following PROTOCOL IDENTIFIER macros can be used to construct
protocolDirID and protocolDirParameters strings.
The sections defining protocol examples are intended to grow over
subsequent releases. Minimal protocol support is included at this
time. (Refer to section 3.2 for details on the protocol macro update
procedure.)
An identifier is encoded by constructing the base-identifier, then
adding one layer-identifier for each encapsulated protocol.
5.1. Base Identifier Encoding
The first layer encapsulation is called the base identifier and it
contains optional protocol-function information and the base layer
(e.g. MAC layer) enumeration value used in this protocol identifier.
The base identifier is encoded as four octets as shown in figure 2.
Fig. 2
base-identifier format
+---+---+---+---+
| | | | |
| f |op1|op2| m |
| | | | |
+---+---+---+---+ octet
| 1 | 1 | 1 | 1 | count
The first octet ('f') is the special function code, found in table
4.1. The next two octets ('op1' and 'op2') are operands for the
indicated function. If not used, an operand must be set to zero. The
last octet, 'm', is the enumerated value for a particular base layer
encapsulation, found in table 4.2. All four octets are encoded in
network-byte-order.
Bierman & Iddon Standards Track [Page 18]
RFC 2074 RMON Protocol Identifiers January 1997
5.1.1. Protocol Identifier Functions
The base layer identifier contains information about any special
functions to perform during collections of this protocol, as well as
the base layer encapsulation identifier.
The first three octets of the identifier contain the function code
and two optional operands. The fourth octet contains the particular
base layer encapsulation used in this protocol (fig. 2).
Table 4.1 Assigned Protocol Identifier Functions
-------------------------------------------------
Function ID Param1 Param2
----------------------------------------------------
none 0 not used (0) not used (0)
wildcard 1 not used (0) not used (0)
5.1.1.1. Function 0: No-op
If the function ID field (1st octet) is equal to zero, the the 'op1'
and 'op2' fields (2nd and 3rd octets) must also be equal to zero.
This special value indicates that no functions are applied to the
protocol identifier encoded in the remaining octets. The identifier
represents a normal protocol encapsulation.
5.1.1.2. Function 1: Protocol Wildcard Function
The wildcard function (function-ID = 1), is used to aggregate
counters, by using a single protocol value to indicate potentially
many base layer encapsulations of a particular network layer
protocol. A protocolDirEntry of this type will match any base-layer
encapsulation of the same protocol.
The 'op1' field (2nd octet) is not used and must be set to zero.
The 'op2' field (3rd octet) is not used and must be set to zero.
Each wildcard protocol identifier must be defined in terms of a 'base
encapsulation'. This should be as 'standard' as possible for
interoperability purposes. If an encapsulation over 'ether2' is
permitted, than this should be used as the base encapsulation.
Bierman & Iddon Standards Track [Page 19]
RFC 2074 RMON Protocol Identifiers January 1997
The agent may also be requested to count some or all of the
individual encapsulations for the same protocols, in addition to
wildcard counting. Note that the RMON-2 MIB [RMON2] does not require
that agents maintain counters for multiple encapsulations of the same
protocol. It is an implementation-specific matter as to how an agent
determines which protocol combinations to allow in the
protocolDirTable at any given time.
5.2. Base Layer Protocol Identifiers
The base layer is mandatory, and defines the base encapsulation of
the packet and any special functions for this identifier.
There are no suggested protocolDirParameters bits for the base layer.
The suggested ProtocolDirDescr field for the base layer is given by
the corresponding "Name" field in the table 4.1 below. However,
implementations are only required to use the appropriate integer
identifier values.
For most base layer protocols, the protocolDirType field should
contain bits set for the 'hasChildren(0)' and
'addressRecognitionCapable(1)' attributes. However, the special
'ianaAssigned' base layer should have no parameter or attribute bits
set.
By design, only 255 different base layer encapsulations are
supported. There are five base encapsulation values defined at this
time. New base encapsulations (e.g. for new media types) are expected
to be added over time.
Table 4.2 Base Layer Encoding Values
--------------------------------------
Name ID
------------------
ether2 1
llc 2
snap 3
vsnap 4
ianaAssigned 5
Bierman & Iddon Standards Track [Page 20]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.1. Ether2 Encapsulation
ether2 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"DIX Ethernet, also called Ethernet-II."
CHILDREN
"The Ethernet-II type field is used to select child protocols.
This is a 16-bit field. Child protocols are deemed to start at
the first octet after this type field.
Children of this protocol are encoded as [ 0.0.0.1 ], the
protocol identifier for 'ether2' followed by [ 0.0.a.b ] where
'a' and 'b' are the network byte order encodings of the MSB and
LSB of the Ethernet-II type value.
For example, a protocolDirID-fragment value of:
0.0.0.1.0.0.8.0 defines IP encapsulated in ether2.
Children of are named as 'ether2' followed by the type field
value in hexadecimal. The above example would be declared as:
ether2 0x0800"
ADDRESS-FORMAT
"Ethernet addresses are 6 octets in network order."
DECODING
"Only type values greater than or equal to 1500 decimal indicate
Ethernet-II frames; lower values indicate 802.3 encapsulation
(see below)."
REFERENCE
"A Standard for the Transmission of IP Datagrams over Ethernet
Networks; RFC 894 [RFC894].
The authoritative list of Ether Type values is identified by the
URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers"
::= { 1 }
Bierman & Iddon Standards Track [Page 21]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.2. LLC Encapsulation
llc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The LLC (802.2) protocol."
CHILDREN
"The LLC SSAP and DSAP (Source/Dest Service Access Points) are
used to select child protocols. Each of these is one octet long,
although the least significant bit is a control bit and should be
masked out in most situations. Typically SSAP and DSAP (once
masked) are the same for a given protocol - each end implicitly
knows whether it is the server or client in a client/server
protocol. This is only a convention, however, and it is possible
for them to be different. The SSAP is matched against child
protocols first. If none is found then the DSAP is matched
instead. The child protocol is deemed to start at the first
octet after the LLC control field(s).
Children of 'llc' are encoded as [ 0.0.0.2 ], the protocol
identifier component for LLC followed by [ 0.0.0.a ] where 'a' is
the SAP value which maps to the child protocol. For example, a
protocolDirID-fragment value of:
0.0.0.2.0.0.0.240
defines NetBios over LLC.
Children are named as 'llc' followed by the SAP value in
hexadecimal. So the above example would have been named:
llc 0xf0"
ADDRESS-FORMAT
"The address consists of 6 octets of MAC address in network
order. Source routing bits should be stripped out of the address
if present."
DECODING
"Notice that LLC has a variable length protocol header; there are
always three octets (DSAP, SSAP, control). Depending on the
value of the control bits in the DSAP, SSAP and control fields
there may be an additional octet of control information.
LLC can be present on several different media. For 802.3 and
802.5 its presence is mandated (but see ether2 and raw802.3
encapsulations). For 802.5 there is no other link layer
protocol.
Bierman & Iddon Standards Track [Page 22]
RFC 2074 RMON Protocol Identifiers January 1997
Notice also that the raw802.3 link layer protocol may take
precedence over this one in a protocol specific manner such that
it may not be possible to utilize all LSAP values if raw802.3 is
also present."
REFERENCE
"The authoritative list of LLC LSAP values is controlled by the
IEEE Registration Authority:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 2 }
5.2.3. SNAP over LLC (OUI=000) Encapsulation
snap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The Sub-Network Access Protocol (SNAP) is layered on top of LLC
protocol, allowing Ethernet-II protocols to be run over a media
restricted to LLC."
CHILDREN
"Children of 'snap' are identified by Ethernet-II type values;
the SNAP PID (Protocol Identifier) field is used to select the
appropriate child. The entire SNAP protocol header is consumed;
the child protocol is assumed to start at the next octet after
the PID.
Children of 'snap' are encoded as [ 0.0.0.3 ], the protocol
identifier for 'snap', followed by [ 0.0.a.b ] where 'a' and 'b'
are the MSB and LSB of the Ethernet-II type value. For example,
a protocolDirID-fragment value of:
0.0.0.3.0.0.8.0
defines the IP/SNAP protocol.
Children of this protocol are named 'snap' followed by the
Ethernet-II type value in hexadecimal. The above example would
be named:
snap 0x0800"
Bierman & Iddon Standards Track [Page 23]
RFC 2074 RMON Protocol Identifiers January 1997
ADDRESS-FORMAT
"The address format for SNAP is the same as that for LLC"
DECODING
"SNAP is only present over LLC. Both SSAP and DSAP will be 0xAA
and a single control octet will be present. There are then three
octets of OUI and two octets of PID. For this encapsulation the
OUI must be 0x000000 (see 'vsnap' below for non-zero OUIs)."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 3 }
5.2.4. SNAP over LLC (OUI != 000) Encapsulation
vsnap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"This pseudo-protocol handles all SNAP packets which do not have
a zero OUI. See 'snap' above for details of those that do."
CHILDREN
"Children of 'vsnap' are selected by the 3 octet OUI; the PID is
not parsed; child protocols are deemed to start with the first
octet of the SNAP PID field, and continue to the end of the
packet.
Children of 'vsnap' are encoded as [ 0.0.0.4 ], the protocol
identifier for 'vsnap', followed by [ 0.a.b.c.0.0.d.e ] where
'a', 'b' and 'c' are the 3 octets of the OUI field in network
byte order. This is in turn followed by the 16-bit EtherType
value, where the 'd' and 'e' represent the MSB and LSB of the
EtherType, respectively.
For example, a protocolDirID-fragment value of:
0.0.0.4.0.8.0.7.0.0.128.155
defines the AppleTalk Phase 2 protocol over vsnap.
Bierman & Iddon Standards Track [Page 24]
RFC 2074 RMON Protocol Identifiers January 1997
Note that two protocolDirParameters octets must be present in
protocolDirTable INDEX values for 'vsnap' protocols. The first
protocolDirParameters octet defines the actual parameters. The
second protocolDirParameters octet is not used and must be set to
zero.
Children are named as 'vsnap(<OUI>) <ethertype>', where the
'<OUI>' field is represented as 3 octets in hexadecimal notation
or the ASCII string associated with the OUI value. The
<ethertype> field is represented by the 2 byte EtherType value in
hexadecimal notation. So the above example would be named:
'vsnap(0x080007) 0x809b' or 'vsnap(apple) 0x809b'"
ADDRESS-FORMAT
"The LLC address format is inherited by 'vsnap'. See the 'llc'
protocol identifier for more details."
DECODING
"Same as for 'snap' except the OUI is non-zero."
REFERENCE
"SNAP Identifier values are assigned by the IEEE Standards
Office. The address is:
IEEE Registration Authority
c/o Iris Ringel
IEEE Standards Dept
445 Hoes Lane, P.O. Box 1331
Piscataway, NJ 08855-1331
Phone +1 908 562 3813
Fax: +1 908 562 1571"
::= { 4 }
5.2.5. IANA Assigned Protocols
ianaAssigned PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This branch contains protocols which do not conform easily to
the hierarchical format utilized in the other link layer
branches. Usually, such a protocol 'almost' conforms to a
particular 'well-known' identifier format, but additional
criteria are used (e.g. configuration-based), making protocol
identification difficult or impossible by examination of
appropriate network traffic. preventing the any 'well-known'
protocol-identifier macro from being used.
Bierman & Iddon Standards Track [Page 25]
RFC 2074 RMON Protocol Identifiers January 1997
Sometimes well-known protocols are simply remapped to a different
port number by one or more venders (e.g. SNMP). These protocols
can be identified with the 'user-extensibility' feature of the
protocolDirTable, and do not need special IANA
assignments.
A centrally located list of these enumerated protocols must be
maintained to insure interoperability.
(See section 3.2 for details on the document update procedure.)
Support for new link-layers will be added explicitly, and only
protocols which cannot possibly be represented in a better way
will be considered as 'ianaEnumerated' protocols.
IANA assigned protocols are identified by the base-layer-selector
value [ 0.0.0.5 ], followed by the four octets [ a.b.c.d ] of the
integer value corresponding to the particular IANA protocol.
Do not create children of this protocol unless you are sure that
they cannot be handled by the more conventional link layers
above."
CHILDREN
"Children of this protocol are identified by implementation-
specific means, described (as best as possible) in the 'DECODING'
clause within the protocol-variant-identifier macro for each
enumerated protocol.
For example, a protocolDirID-fragment value of:
0.0.0.5.0.0.0.1
defines the IPX protocol encapsulated directly in 802.3
Children are named 'ianaAssigned' followed by the name or numeric
of the particular IANA assigned protocol. The above
example would be named:
'ianaAssigned 1' or 'ianaAssigned ipxOverRaw8023'"
DECODING
"The 'ianaAssigned' base layer is a pseudo-protocol and is not
decoded."
REFERENCE
"Refer to individual PROTOCOL-IDENTIFIER macros for information
on each child of the IANA assigned protocol."
::= { 5 }
Bierman & Iddon Standards Track [Page 26]
RFC 2074 RMON Protocol Identifiers January 1997
5.2.5.1. IANA Assigned Protocol Identifiers
The following protocol-variant-identifier macro declarations are used
to identify the RMONMIB IANA assigned protocols in a proprietary way,
by simple enumeration. Note that an additional four-octet layer
identifier may be used for some enumerations (as with the 'vsnap'
base-layer identifier). Refer to the 'CHILDREN' clause in the
protocol-identifier macro for a particular protocol to determine the
number of octets in the 'ianaAssigned' layer-identifier.
ipxOverRaw8023 PROTOCOL-IDENTIFIER
VARIANT-OF "ipx"
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"This pseudo-protocol describes an encapsulation of IPX over
802.3, without a type field.
Refer to the macro for IPX for additional information about this
protocol."
DECODING
"Whenever the 802.3 header indicates LLC a set of protocol
specific tests needs to be applied to determine whether this is a
'raw8023' packet or a true 802.2 packet. The nature of these
tests depends on the active child protocols for 'raw8023' and is
beyond the scope of this document."
::= { ianaAssigned 1 }
5.3. L3: Children of Base Protocol Identifiers
Network layer protocol identifier macros contain additional
information about the network layer, and is found immediately
following a base layer-identifier in a protocol identifier.
The ProtocolDirParameters supported at the network layer are
'countsFragments(0)', and 'tracksSessions(1). An agent may choose to
implement a subset of these parameters.
The protocol-name should be used for the ProtocolDirDescr field. The
ProtocolDirType ATTRIBUTES used at the network layer are
'hasChildren(0)' and 'addressRecognitionCapable(1)'. Agents may
choose to implement a subset of these attributes for each protocol,
and therefore limit which tables the indicated protocol can be
present (e.g. protocol distribution, host, and matrix tables)..
The following protocol-identifier macro declarations are given for
example purposes only. They are not intended to constitute an
exhaustive list or an authoritative source for any of the protocol
Bierman & Iddon Standards Track [Page 27]
RFC 2074 RMON Protocol Identifiers January 1997
information given. However, any protocol that can encapsulate other
protocols must be documented here in order to encode the children
identifiers into protocolDirID strings. Leaf protocols should be
documented as well, but an implementation can identify a leaf
protocol even if it isn't listed here (as long as the parent is
documented).
5.3.1. IP
ip PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0) -- This parameter applies to all child
-- protocols.
}
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"The protocol identifiers for the Internet Protocol (IP). Note
that IP may be encapsulated within itself, so more than one of
the following identifiers may be present in a particular
protocolDirID string."
CHILDREN
"Children of 'ip' are selected by the value in the Protocol field
(one octet), as defined in the PROTOCOL NUMBERS table within the
Assigned Numbers Document.
The value of the Protocol field is encoded in an octet string as
[ 0.0.0.a ], where 'a' is the protocol field .
Children of 'ip' are encoded as [ 0.0.0.a ], and named as 'ip a'
where 'a' is the protocol field value. For example, a
protocolDirID-fragment value of:
0.0.0.1.0.0.8.0.0.0.0.1
defines an encapsulation of ICMP (ether2.ip.icmp)"
ADDRESS-FORMAT
"4 octets of the IP address, in network byte order. Each ip
packet contains two addresses, the source address and the
destination address."
DECODING
"Note: ether2/ip/ipip4/udp is a different protocolDirID than
ether2/ip/udp, as identified in the protocolDirTable. As such,
two different local protocol index values will be assigned by the
agent. E.g. (full INDEX values shown):
ether2/ip/ipip4/udp 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.4.0.0.0.0
ether2/ip/udp 12.0.0.0.1.0.0.8.0.0.0.0.17.3.0.0.0 "
Bierman & Iddon Standards Track [Page 28]
RFC 2074 RMON Protocol Identifiers January 1997
REFERENCE
"RFC 791 [RFC791] defines the Internet Protocol; The following
URL defines the authoritative repository for the PROTOCOL NUMBERS
Table:
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers"
::= {
ether2 0x0800,
llc 0x06,
snap 0x0800,
ip 4,
ip 94
}
5.3.2. IPX
ipx PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Novell IPX"
CHILDREN
"Children of IPX are defined by the 16 bit value of the
Destination Socket field. The value is encoded into an octet
string as [ 0.0.a.b ], where 'a' and 'b' are the network byte
order encodings of the MSB and LSB of the destination socket
field."
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"The IPX protocol is defined by the Novell Corporation
Bierman & Iddon Standards Track [Page 29]
RFC 2074 RMON Protocol Identifiers January 1997
A complete description of IPX may be secured at the following
address:
Novell, Inc.
122 East 1700 South
P. O. Box 5900
Provo, Utah 84601 USA
800 526 5463
Novell Part # 883-000780-001"
::= {
ether2 0x8137, -- 0.0.129.55
llc 0xe0e003, -- 0.224.224.3
snap 0x8137, -- 0.0.129.55
ianaAssigned 0x1 -- 0.0.0.1 (ipxOverRaw8023)
}
5.3.3. ARP
arp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"An Address Resolution Protocol message (request or response).
This protocol does not include Reverse ARP (RARP) packets, which
are counted separately."
REFERENCE
"RFC 826 [RFC826] defines the Address Resolution Protocol."
::= {
ether2 0x806, -- [ 0.0.8.6 ]
snap 0x806
}
5.3.4. IDP
idp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"Xerox IDP"
CHILDREN
"Children of IDP are defined by the 8 bit value of the Packet
type field. The value is encoded into an octet string as [
0.0.0.a ], where 'a' is the value of the packet type field in
network byte order."
Bierman & Iddon Standards Track [Page 30]
RFC 2074 RMON Protocol Identifiers January 1997
ADDRESS-FORMAT
"4 bytes of Network number followed by the 6 bytes Host address
each in network byte order".
REFERENCE
"Xerox Corporation, Document XNSS 028112, 1981"
::= {
ether2 0x600, -- [ 0.0.6.0 ]
snap 0x600
}
5.3.5. AppleTalk ARP
atalkarp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"AppleTalk Address Resolution Protocol."
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x80f3, -- [ 0.0.128.243 ]
vsnap(0x080007) 0x80f3
}
5.3.6. AppleTalk
atalk PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0),
addressRecognitionCapable(1)
}
DESCRIPTION
"AppleTalk Protocol."
CHILDREN
"Children of ATALK are defined by the 8 bit value of the DDP type
field. The value is encoded into an octet string as [ 0.0.0.a ],
where 'a' is the value of the DDP type field in network byte
order."
ADDRESS-FORMAT
"2 bytes of Network number followed by 1 byte of node id each in
network byte order".
Bierman & Iddon Standards Track [Page 31]
RFC 2074 RMON Protocol Identifiers January 1997
REFERENCE
"AppleTalk Phase 2 Protocol Specification, document ADPA
#C0144LL/A."
::= {
ether2 0x809b, -- [ 0.0.128.155 ]
vsnap(0x080007) 0x809b
}
5.4. L4: Children of L3 Protocols
5.4.1. ICMP
icmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Internet Message Control Protocol."
REFERENCE
"RFC 792 [RFC792] defines the Internet Control Message Protocol."
::= { ip 1 }
5.4.2. TCP
tcp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"Transmission Control Protocol."
CHILDREN
"Children of TCP are identified by the 16 bit Destination Port
value as specified in RFC 793. They are encoded as [ 0.0.a.b],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23
identifies an encapsulation of the telnet protocol
(ether2.ip.tcp.telnet)"
REFERENCE
"RFC 793 [RFC793] defines the Transmission Control Protocol.
The following URL defines the authoritative repository for
reserved and registered TCP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 6 }
Bierman & Iddon Standards Track [Page 32]
RFC 2074 RMON Protocol Identifiers January 1997
5.4.3. UDP
udp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0)
}
DESCRIPTION
"User Datagram Protocol."
CHILDREN
"Children of UDP are identified by the 16 bit Destination Port
value as specified in RFC 768. They are encoded as [ 0.0.a.b ],
where 'a' is the MSB and 'b' is the LSB of the Destination Port
value. Both bytes are encoded in network byte order. For
example, a protocolDirId-fragment of:
0.0.0.1.0.0.8.0.0.0.0.17.0.0.0.161
identifies an encapsulation of SNMP (ether2.ip.udp.snmp)"
REFERENCE
"RFC 768 [RFC768] defines the User Datagram Protocol.
The following URL defines the authoritative repository for
reserved and registered UDP port values:
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers"
::= { ip 17 }
5.5. L5: Application Layer Protocols
5.5.1. FTP
5.5.1.1. FTP-DATA
ftp-data PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Data Port; the FTP Server process
default data-connection port. "
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol. Refer to
section 3.2 of [RFC959] for details on FTP data connections."
::= { tcp 20 }
Bierman & Iddon Standards Track [Page 33]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.1.2. FTP Control
ftp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The File Transfer Protocol Control Port; An FTP client initiates
an FTP control connection by sending FTP commands from user port
(U) to this port."
REFERENCE
"RFC 959 [RFC959] defines the File Transfer Protocol."
::= { tcp 21 }
5.5.2. Telnet
telnet PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Telnet Protocol; The purpose of the TELNET Protocol is to
provide a fairly general, bi-directional, eight-bit byte oriented
communications facility. Its primary goal is to allow a standard
method of interfacing terminal devices and terminal-oriented
processes to each other. "
REFERENCE
"RFC 854 [RFC854] defines the basic Telnet Protocol."
::= { tcp 23 }
5.5.3. SMTP
smtp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"The Simple Mail Transfer Protocol; SMTP control and data
messages are sent on this port."
REFERENCE
"RFC 821 [RFC821] defines the basic Simple Mail Transfer
Protocol."
::= { tcp 25 }
Bierman & Iddon Standards Track [Page 34]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.4. DNS
domain PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Domain Name Service Protocol; DNS may be transported by either
UDP [RFC768] or TCP [RFC793]. If the transport is UDP, DNS
requests restricted to 512 bytes in length may be sent to this
port."
REFERENCE
"RFC 1035 [RFC1035] defines the Bootstrap Protocol."
::= { udp 53,
tcp 53 }
5.5.5. BOOTP
5.5.5.1. Bootstrap Server Protocol
bootps PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Server Protocol; BOOTP Clients send requests
(usually broadcast) to the bootps port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 67 }
5.5.5.2. Bootstrap Client Protocol
bootpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Bootstrap Protocol Client Protocol; BOOTP Server replies are
sent to the BOOTP Client using this destination port."
REFERENCE
"RFC 951 [RFC951] defines the Bootstrap Protocol."
::= { udp 68 }
Bierman & Iddon Standards Track [Page 35]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.6. TFTP
tftp PROTOCOL-IDENTIFIER
PARAMETERS {
tracksSessions(1)
}
ATTRIBUTES { }
DESCRIPTION
"Trivial File Transfer Protocol; Only the first packet of each
TFTP transaction will be sent to port 69. If the tracksSessions
attribute is set, then packets for each TFTP transaction will be
attributed to tftp, instead of the unregistered port numbers that
will be encoded in subsequent packets."
REFERENCE
"RFC 1350 [RFC1350] defines the TFTP Protocol (revision 2); RFC
1782 [RFC1782] defines TFTP Option Extensions; RFC 1783 [RFC1783]
defines the TFTP Blocksize Option; RFC 1784 [RFC1784] defines
TFTP Timeout Interval and Transfer Size Options."
::= { udp 69 }
5.5.7. HTTP
www-http PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Hypertext Transfer Protocol; "
REFERENCE
"RFC 1945 [RFC1945] defines the Hypertext Transfer Protocol
(HTTP/1.0)."
::= { tcp 80 }
5.5.8. POP3
pop3 PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Post Office Protocol -- Version 3. Clients establish connections
with POP3 servers by using this destination port number."
REFERENCE
"RFC 1725 [RFC1725] defines Version 3 of the Post Office
Protocol."
::= { tcp 110 }
Bierman & Iddon Standards Track [Page 36]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.9. SUNRPC
sunrpc PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES {
hasChildren(0) -- port mapper function numbers
}
DESCRIPTION
"SUN Remote Procedure Call Protocol. Port mapper function
requests are sent to this destination port."
CHILDREN
Specific RPC functions are represented as children of the sunrpc
protocol. Each 'RPC function protocol' is identified by its
function number assignment. RPC function number assignments are
defined by different naming authorities, depending of the
function identifier value.
From [RFC1831]:
Program numbers are given out in groups of hexadecimal 20000000
(decimal 536870912) according to the following chart:
0 - 1fffffff defined by rpc@sun.com
20000000 - 3fffffff defined by user
40000000 - 5fffffff transient
60000000 - 7fffffff reserved
80000000 - 9fffffff reserved
a0000000 - bfffffff reserved
c0000000 - dfffffff reserved
e0000000 - ffffffff reserved
Children of 'sunrpc' are encoded as [ 0.0.0.111], the protocol
identifier component for 'sunrpc', followed by [ a.b.c.d ], where
a.b.c.d is the 32 bit binary RPC program number encoded in
network byte order. For example, a protocolDirID-fragment value
of:
0.0.0.111.0.1.134.163
defines the NFS function (and protocol).
Children are named as 'sunrpc' followed by the RPC function
number in base 10 format. For example, NFS would be named:
'sunrpc 100003'.
REFERENCE
"RFC 1831 [RFC1831] defines the Remote Procedure Call Protocol
Version 2. The authoritative list of RPC Functions is identified
by the URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/sun-rpc-numbers"
::= { udp 111 }
Bierman & Iddon Standards Track [Page 37]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.10. NFS
nfs PROTOCOL-IDENTIFIER
PARAMETERS {
countsFragments(0)
}
ATTRIBUTES { }
DESCRIPTION
"Sun Network File System (NFS);"
DECODING
"The first packet in an NFS transaction is sent to the port-
mapper, and therefore decoded statically by monitoring RFC
portmap requests [RFC1831]. Any subsequent NFS fragments must be
decoded and correctly identified by 'remembering' the port
assignments used in each RPC function call (as identified
according to the procedures in the RPC Specification Version 2
[RFC1831]).
The 'countsFragments(0)' PARAMETER bit is used to indicate
whether the probe can (and should) monitor portmapper activity to
correctly attribute all NFS packets."
REFERENCE
"The NFS Version 3 Protocol Specification is defined in RFC 1813
[RFC1813]."
::= {
sunrpc 100003 -- [0.1.134.163]
}
5.5.11. SNMP
5.5.11.1. SNMP Request/Response
snmp PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol. Includes SNMPv1 and SNMPv2
protocol versions. Does not include SNMP trap packets."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 161,
ipx 0x900f, -- [ 0.0.144.15 ]
atalk 8
}
Bierman & Iddon Standards Track [Page 38]
RFC 2074 RMON Protocol Identifiers January 1997
5.5.11.2. SNMP Trap
snmptrap PROTOCOL-IDENTIFIER
PARAMETERS { }
ATTRIBUTES { }
DESCRIPTION
"Simple Network Management Protocol Trap Port."
REFERENCE
"The SNMP SMI is defined in RFC 1902 [RFC1902]. The SNMP
protocol is defined in RFC 1905 [RFC1905]. Transport mappings
are defined in RFC 1906 [RFC1906]; RFC 1420 (SNMP over IPX)
[RFC1420]; RFC 1419 (SNMP over AppleTalk) [RFC1419]."
::= {
udp 162,
ipx 0x9010,
atalk 9
}
6. Acknowledgements
This document was produced by the IETF RMONMIB Working Group.
The authors wish to thank the following people for their
contributions to this document:
Anil Singhal
Frontier Software Development, Inc.
Jeanne Haney
Bay Networks
Dan Hansen
Network General Corp.
Bierman & Iddon Standards Track [Page 39]
RFC 2074 RMON Protocol Identifiers January 1997
7. References
[RFC768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[RFC791]
Postel, J., ed., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, USC/Information Sciences
Institute, September 1981.
[RFC792]
Postel, J., "Internet Control Message Protocol - DARPA Internet
Program Protocol Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[RFC793]
Postel, J., "Transmission Control Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 793, USC/Information Sciences
Institute, September 1981.
[RFC821]
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[RFC826]
Plummer, D., "An Ethernet Address Resolution Protocol or
"Converting Network Protocol Addresses to 48-bit Ethernet Addresses
for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT-LCS,
November 1982.
[RFC854]
Postel, J. and J. Reynolds, "Telnet Protocol Specification",
STD 8, RFC 854, ISI, May 1983.
[RFC894]
Hornig, C., "A Standard for the Transmission of IP Datagrams over
Ethernet Networks", RFC 894, Symbolics, April 1984.
[RFC951]
Croft, B., and J. Gilmore, "BOOTSTRAP Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsytems, September 1985.
[RFC959]
Postel, J., and J. Reynolds, "File Transfer Protocol", STD 8,
RFC 959, USC/Information Sciences Institute, October 1985.
Bierman & Iddon Standards Track [Page 40]
RFC 2074 RMON Protocol Identifiers January 1997
[RFC1035]
Mockapetris, P., "Domain Names - Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[RFC1157]
Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[RFC1213]
McCloghrie, K., and M. Rose, Editors, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II", STD 17,
RFC 1213, Hughes LAN Systems, Performance Systems International,
March 1991.
[RFC1350]
Sollins, K., "TFTP Protocol (revision 2)", RFC 1350, MIT, July
1992.
[RFC1419]
Minshall, G., and M. Ritter, "SNMP over AppleTalk", RFC 1419,
Novell, Inc., Apple Computer, Inc., March 1993.
[RFC1420]
Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
[RFC1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[RFC1725]
Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
[RFC1757]
S. Waldbusser, "Remote Network Monitoring MIB", RFC 1757, Carnegie
Mellon University, February 1995.
[RFC1782]
Malkin, G., and A. Harkin, T "TFTP Option Extension", RFC 1782,
Xylogics, Inc., Hewlett Packard Co., March 1995.
[RFC1783]
Malkin, G., and A. Harkin, T "TFTP BlockOption Option", RFC 1783,
Xylogics, Inc., Hewlett Packard Co., March 1995.
Bierman & Iddon Standards Track [Page 41]
RFC 2074 RMON Protocol Identifiers January 1997
[RFC1784]
Malkin, G., and A. Harkin, "TFTP Timeout Interval and Transfer Size
Options", RFC 1784, Xylogics, Inc., Hewlett Packard Co., March
1995.
[RFC1800]
Postel, J., Editor, "Internet Official Protocol Standards", STD 1,
RFC 1920, IAB, March 1996.
[RFC1831]
Srinivasan, R., "Remote Procedure Call Protocol Version 2", RFC
1831, Sun Microsystems, Inc., August 1995.
[RFC1902]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[RFC1903]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[RFC1904]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Conformance Statements for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[RFC1905]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1906]
SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1945]
Berners-Lee, T., and R. Fielding, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, MIT/UC-Irvine, November 1995.
[RMON2]
S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", draft-
ietf-rmonmib-rmon2-03.txt, International Network Services, January
1996.
Bierman & Iddon Standards Track [Page 42]
RFC 2074 RMON Protocol Identifiers January 1997
8. Security Considerations
Security issues are not discussed in this memo.
9. Authors' Addresses
Andy Bierman
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: 408-527-3711
EMail: abierman@cisco.com
Robin Iddon
3Com/AXON
40/50 Blackfrias Street
Edinburgh, UK
Phone: +44 131.558.3888
EMail: robin_iddon@3mail.3com.com
Bierman & Iddon Standards Track [Page 43]
|